Борри хелен firebird руководство разработчика баз данных скачать - RukovodstvoRus.ru

Хелен Борри

Firebird

РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Введение

Об авторе

Хелен Борри (Helen Borrie) работает по контракту инженером по программному обеспечению, по совместительству писательница и технический редактор. Она занимается разработкой баз данных более 20 лет, а с Firebird и его предшественниками работает с 1996 года.

Хелен — активный участник сообщества онлайновой поддержки Firebird и одна из основателей FirebirdSQL Foundation Inc.

Хелен живет в Австралии и общается через Интернет из своей домашней студии, расположенной среди эвкалиптов на живописном берегу Нового Южного Уэльса.

О техническом редакторе

Джефф Ворбойз (Geoff Worboys) занимается проектированием и разработкой приложений, связанных с базами данных, около 15 лет. В течение последних более 10 лет он использует Firebird, а перед этим применял его предшественника InterBase в качестве системы управления реляционными базами данных в разработке приложений, инструментов управления и компонентов для Delphi, С и C++ в зависимости от ситуации.

Сейчас он работает в укромном офисе в Новом Южном Уэльсе, Австралия, разрабатывая приложения как для клиентов из Австралии, так и для клиентов из других стран. Он наблюдает кенгуру и других обитателей дикой природы из своего окна, размышляя над проблемами проектирования баз данных и приложений — Интернет замечательная штука.

О научном редакторе перевода на русский язык

Кузьменко Дмитрий занимается проектированием и разработкой приложений баз данных уже 16 лет. С InterBase начал работать в 1994 году. В 2002 году Дмитрий основал фирму iBase (www.ibase.ru), которая занимается техническим сопровождением InterBase и Firebird, а также обучением, консультациями и продажей программных продуктов.

Дмитрий живет и работает в Москве, видел кенгуру только в зоопарке и по каналу Discovery и не откажется при удобном случае посетить Австралию.

Благодарности

Вот, наконец, мы с книгой по Firebird в руках! Ее написание избавило меня от других рискованных занятий в течение почти года. Я постоянно беспокоила моих хороших друзей из сообщества Firebird, так что я должна вначале поблагодарить всех их, даже если я не назову каждого по имени. У нас есть наша книга, спасибо вам.

Павел Цизар (Pavel Cisar), мой давнишний друг по онлайновой поддержке из Kingdom of Geek, уделял мне свое время и опыт, выходящие за рамки его обязанностей. Павел был опорой издательской группы, он также давал отдельные неоценимые советы на основании опыта написания своей собственной книги по Firebird и InterBase в прошлом году (в Чехии) и его исследований внутренней работы оптимизатора запросов. Анна Харрисон (Ann Harrison)- «мать InterBase», превосходный специалист в большинстве премудростей сервера Firebird. Иван Преносил (Ivan Prenosil) щедро делился полученным им практическим опытом, а проницательность Дмитрия Серебрякова избавила меня от многих оплошностей. Клавдио Валдеррама (Claudio Valderrama Cortes) делился своим пониманием секретов RDB$DB_KEY. Спасибо также Дэвиду Брукстоуну Шнепперу (David Brookestone Schnepper) за полезные комментарии о наборах символов и Грегори Дицу (Gregory Deatz) за предоставление мне документа по внешним функциям FreeUDFLib в приложении 1.

Моему другу Джеффу Ворбойзу особая благодарность за огромную заботу и терпение, которые он проявил при техническом просмотре содержания книги и многих деталей. Мы не всегда были согласны друг с другом, но книга по Firebird стала лучше благодаря ему. Спасибо также Дугу Чамберлину (Doug Chamberlin) и Иоане Пирте (Ioana Pirtea) за их просмотр «читательскими глазами».

Я также благодарна директорам компании IBPhoenix Полу Бигу (Paul Beach) и Анне Харрисон, а также моим сотрудникам за то, что помогли мне в вопросах временных задержек и финансирования книги.

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

И, наконец, я должна от всего сердца от имени всех нас сказать «спасибо» разработчикам Firebird, чьи увлеченность, умения и самоотверженность дали нам Firebird.

Kia ora! Kia manawa!

Хелен Борри

Апрель 2004

Введение в Firebird

Что такое Firebird?

Firebird — это мощная, компактная реляционная система управления базами данных (РСУБД) с архитектурой клиент-сервер. Она может выполняться на разнообразных серверных и клиентских платформах, включая Windows, Linux и на некоторых других платформах UNIX, включая FreeBSD и Mac OS X. Это РСУБД промышленного применения, чьи возможности имеют высокий уровень соответствия стандартам SQL, при этом она реализует некоторые мощные расширения языка процедурного программирования конкретного производителя.

Кому нужна эта книга?

Разработчики с некоторым опытом работы с базами данных, которые, возможно, переходят на платформу клиент-сервер впервые, найдут в этой книге все необходимое, чтобы стать более продуктивными в Firebird. Несмотря на то, что это руководство не является начальным учебником по SQL или по проектированию баз данных, в нем делается акцент на практику проектирования хороших приложений на базе клиент- серверных реляционных СУБД; оно также содержит документацию по языку SQL для Firebird — определения, манипуляция, язык программирования — с большим количеством деталей, советов и примеров.

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

Тех кто использовал до настоящего момента Firebird 1.0.x или InterBase, книга по Firebird знакомит с расширениями языка, безопасностью и возможностями оптимизатора, которые были добавлены в версию 1.5.

Где найти нужную вам информацию?

Часть I является «учебным лагерем» для новичков в Firebird. Здесь вы найдете основные сведения по инсталляции программного обеспечения, созданию и запуску клиента сети и некоторые полезные установки конфигурации. Эта часть завершается главой по самым основным операциям: соединение с базой данных примера и создание вашей первой собственной базы данных с использованием утилиты isql, входящей в состав Firebird. В этой части вводятся различные инструменты командной строки для администратора и рассказывается, как запустить и остановить сервер.

Часть II содержит обзор концепций и моделей архитектуры клиент-сервер и описание того, насколько им соответствует реализация Firebird. Финальная глава этой части содержит некоторые общие практические инструкции по использованию клиентских библиотек Firebird.

В части III вы найдете детальное описание каждого типа данных SQL, поддерживаемого Firebird. Существует отдельная глава для каждого класса типа данных — числа, тип дата/время, символьные типы и т.д. — с множеством советов по их использованию.

Часть IV исследует объекты базы данных в подробностях, начиная с самой базы данных и переходя к таблицам, индексам и другим типам объектов. Синтаксис и использование операторов языка определения данных (Data Definition Language, DDL) представлены в этой части.

Часть V содержит документацию по языку манипулирования данными (Data Manipulation Language, DML), используемому в SQL Firebird.

Часть V1 описывает транзакции: как они работают, как их конфигурировать, и содержит советы по их использованию в ваших прикладных программах.

Часть VII описывает программирование на стороне сервера в Firebird: написание триггеров и хранимых процедур, создание и использование событий базы данных, обработка ошибок в вашем коде на сервере.

Часть VIII посвящена вопросам безопасности, архитектуры и конфигурации.

Последняя часть IX документирует инструменты командной строки и их оболочки для администрирования.

Приложения и глоссарий

В приложениях и глоссарии представлены следующие материалы и детали.

Приложение 1 содержит имена, описания и примеры внешних функций (UDF, User- defined functions, Определенные пользователем функции), поставляемых в библиотеках fb_udf и ib_udf для платформ POSIX (Portable Operating System Interface for UNIX, Интерфейс переносимых операционных систем) и в свободно распространяемой Грегори Дитцем FreeUDFLib.dll для Windows.

Приложение 2 является собранием советов по устранению ошибок; к нему вы можете обратиться, когда встречаются проблемы соединения удаленных клиентов с сервером Firebird.

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

Источник

Хелен Борри
Firebird
РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Введение

Об авторе

Хелен — активный участник сообщества онлайновой поддержки Firebird и одна из основателей FirebirdSQL Foundation Inc.

О техническом редакторе

О научном редакторе перевода на русский язык

Благодарности

Kia ora! Kia manawa!

Хелен Борри

Апрель 2004

Введение в Firebird

Что такое Firebird?

Кому нужна эта книга?

Где найти нужную вам информацию?

Часть V содержит документацию по языку манипулирования данными (Data Manipulation Language, DML), используемому в SQL Firebird.

Часть VIII посвящена вопросам безопасности, архитектуры и конфигурации.

Последняя часть IX документирует инструменты командной строки и их оболочки для администрирования.

Приложения и глоссарий

В приложениях и глоссарии представлены следующие материалы и детали.

Приложение 3 суммирует информацию о некоторых основных драйверах и средствах программного интерфейса, доступных в Firebird. Содержит адреса сайтов загрузки и поддержки этих материалов.

Приложение 4 описывает пошаговую процедуру, которой вы должны следовать, если обнаружили логические ошибки в базе данных Firebird.

Приложение 5 описывает множество графических инструментов, доступных для работы с вашими базами данных Firebird. Содержит ссылки на адреса загрузки инструментов.

Приложение 6 содержит некоторые замечания о базе данных employee.fdb (employee.gdb в версии 1.0.x), которую инсталлятор Firebird устанавливает в подкаталоге examples вашего корневого каталога Firebird.

Приложение 7 перечисляет различные физические ограничения, применимые к базам данных Firebird 1.0.x и 1.5.

Приложение 8 является полным справочником по интернациональным наборам символов и связанным с языками порядкам сортировки, поставляемым с Firebird 1.5.

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

Приложение 10 содержит полный список в виде таблицы кодов исключений (SQLCODE и GDSCODE), определенных в Firebird 1.5, вместе с соответствующими символическими константами и текстами сообщений на английском языке.

Приложение 11 содержит список всех ключевых слов, которые Firebird 1.0.x и 1.5 трактует как зарезервированные слова.

Приложение 12 — собрание ресурсов, доступных пользователям Firebird. Содержит книги и другие документированные рекомендации и описания, а также ссылки на форумы поддержки.

Глоссарий содержит детальные описания терминологии и концепций, которые вы, скорее всего, встретите при вашем путешествии по Firebird. Данные были получены из опросов опытных и не слишком опытных членов сообщества Firebird, которых попросили предоставить «список пожеланий» для глоссария.

Происхождение Firebird

Созданный как проект с открытыми исходными кодами, Firebird является первым в новом поколении потомков InterBase 6.0 Open Edition фирмы Borland, который был сформирован для разработки открытых исходных кодов в июле 2000 г. в рамках InterBase Public License (IPL).

Исходные коды Firebird поддерживаются и развиваются на основании международного открытого кода на сайте SourceForge.net (http://sourceforge.net), большой группой профессиональных разработчиков, в которую входят добровольцы и наемные специалисты, получающие частичное финансирование из сообщества и коммерческих источников.

! ! !

СОВЕТ. Продукты реляционной СУБД Firebird и некоторые связанные модули распространяются полностью свободными от регистрации или гонорара на основании универсальной лицензии на открытые коды. Проект Firebird, его разработчики и его программное обеспечение никак не связаны с Borland Software Corporation.

. ! .

Проект Firebird

Разработка

Разработчики, проектировщики и тестеры, кто предоставил вам Firebird и некоторые драйверы, являются членами проекта открытых кодов Firebird в SourceForge, изумительного виртуального сообщества, которое является домом для тысяч групп программного обеспечения с открытыми кодами. Адрес проекта Firebird: http://sourceforge.net/projects/firebird. На этом сайте находятся исходные коды CVS, сообщения об обнаруженных ошибках и множество технических файлов, которые могут быть загружены для различных целей, связанных с разработкой и тестированием кода.

Разработчики и тестеры проекта Firebird используют форум firebird-devel@lists.sourceforge.net в качестве своей «виртуальной лаборатории» для общения друг с другом по вопросам улучшения, исправления ошибок и создания новых версий Firebird.

Любой, кто хочет наблюдать продвижение вперед и иметь обратную связь по вопросам разработки бета-версий, может присоединиться к этому форуму.

Поддержка разработчиков приложений и администраторов базы данных

Firebird имеет мощное сообщество добровольных помощников, включая большую группу активных разработчиков с многолетним опытом разработки и распространения Firebird и его предшественника InterBase. Чувство солидарности в этой большой группе таково, что, приобретя умения и изучив «внутренние хитрости» по советам других людей, члены группы создают соответствующий список для обучения других пользователей. Основным каналом свободной поддержки является форум поддержки Firebird.

Специализированные группы проекта поддерживают соответствующие форумы: Java, Delphi, C++ Builder, инструменты, Visual Basic, .NET, PHP и др. Группы представлены в виде списков e-mail, многие из них отображаются на сервере новостей. Самые свежие ссылки на эти форумы всегда могут быть найдены на главном Web- сайте сообщества (http://www.firebirdsql.org) и на дочернем коммерческом сайте IBPhoenix (http://www.ibphoenix.com).

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

В приложении 12 смотрите исчерпывающий список ресурсов поддержки сообщества.

FirebirdSQL Foundation

FirebirdSQL Foundation Inc. — это некоммерческий фонд, зарегистрированный в Новом Южном Уэльсе в Австралии, который собирает во всем мире денежные средства для предоставления разработчикам, работающим над основным и специальными проектами для развития, тестирования и улучшения Firebird. Средства поступают в виде частной и корпоративной спонсорской помощи, пожертвований или членских взносов. Это предоставляет возможность благодарным пользователям Firebird возвращать вложения за свободное использование программного обеспечения и поддержку сообщества. (См. на http://www.firebirdsql.org/ff/foundation.)

Спарки

Спарки, молодой, алый феникс с зеленым клювом — талисман Firebird. Спарки крутился возле проекта Firebird в различных нарядах с самого начала, однако он впервые появился «как персона» на Первой международной конференции по Firebird в г. Фулда в Германии, в мае 2003 года.

Обзор возможностей

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

! ! !

ВНИМАНИЕ! Администрирование и разработка в полноценной SQL реляционной СУБД на платформе клиент-сервер, вероятно, являются совершенно новой для вас территорией. Вам это может показаться слишком сложным, если вы впервые отважились обратиться к программному обеспечению управления данными, в котором заложена возможность существования множества параллельных процессов. Часть II этой книги содержит введение в концепцию клиент-сервер. Если вы почувствуете, что теряетесь в следующих описаниях, вы можете тут же обратиться к части II, чтобы освоить контекст.

. ! .

Версии Firebird

Двоичные файлы Firebird версии 1.0.x были разработаны для корректировки и улучшения написанных на языке С модулей, которые сообщество открытых исходных текстов наследовало от InterBase 6.0. Для Firebird 1.5 модули были полностью переписаны на C++ с высокой степенью стандартизации.

Переход от версии 1 к версии 1.5 был в большей мере внутренним, интерфейс прикладного программирования (Application Programming Interface, API) не изменился. Программное обеспечение приложений, написанное для версии 1, требует небольших (или вообще никаких) изменений для работы с версией 1.5.

И хотя рекомендуется установить и использовать самую последнюю версию, несовместимость операционных систем означает (при всем уважении к Linux), что последняя версия 1.0.x- единственный выбор для некоторых сайтов. Многие новшества версии 1.5 были привнесены в версию 1.0.x, и регулярно выпускаются дополнительные сборки.

Доступ к сети

Сервер Firebird, запущенный на любой платформе, принимает TCP/IP-подключения клиентов с любой клиентской платформы, которая может выполнять Firebird API.

Клиенты не могут подключиться к серверу Firebird через какую-нибудь файловую систему коллективного доступа (NFS, соединение клиентов Samba, общие ресурсы Windows или сетевой диск и т.д.).

Клиент должен подключаться с указанием абсолютного физического пути. Тем не менее в Firebird 1.5 и выше средство алиасов баз данных позволяет приложениям выполнять «мягкое подключение» с использованием именованных алиасов, чьи абсолютные пути указаны специально для каждого сервера.

К серверу Firebird, запущенному на хосте в Windows с сервисами, можно получить доступ от клиентов Windows с помощью сетевого протокола Named Pipes (именованные каналы).

Многоверсионная архитектура

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

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

По причине использования многоверсионной архитектуры (называемой также MGA — Multi-generational architecture) для Firebird нет необходимости в двухфазной блокировке, используемой другими СУБД для управления многопользовательской работой.

Транзакции

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

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

Транзакции в Firebird являются атомарными в том смысле, что вся работа в рамках транзакции будет сохранена или вся отменена.

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

Хранимые процедуры и триггеры

Firebird имеет богатый язык процедурных расширений, PSQL, для написания хранимых процедур и триггеров. Это структурированный язык с поддержкой циклов FOR для множеств, условными переходами, обработкой ошибок и пересылкой событий. После создания код PSQL компилируется и сохраняется в двоичном виде.

Триггеры имеют сильную поддержку с фазами До (Before) и После (After) каждого события манипулирования данными. Для каждой фазы/события может существовать множество триггеров, они могут содержать номера, задающие последовательность выполнения. Firebird 1.5 и выше поддерживает триггеры Before и After, которые обрабатывают все три события манипулирования данными с условными переходами для каждого события.

Ссылочная целостность

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

Оперативное копирование базы данных

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

Оперативное копирование не является репликацией.

Безопасность

Безопасность сервера

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

! ! !

ВНИМАНИЕ! Поскольку встраиваемый сервер (см. разд. «Встраиваемый сервер») разработан для однопользовательских, автономных приложений, он совершенно не проверяет безопасность для хоста. Привилегии SQL, заданные на уровне базы данных, еще применяются, но приложение через встраиваемый сервер может получить доступ к любой базе данных на этом компьютере без указания пароля. (См. главу 34.)

. ! .

Привилегии SQL

Хотя пользователь должен быть авторизован для доступа к серверу Firebird, но никакой пользователь, за исключением SYSDBA и владельца базы данных, не имеет автоматически никаких прав на индивидуальную базу данных. Безопасность на уровне базы данных поддерживается посредством привилегий SQL. Пользователям должны быть явно предоставлены привилегии к любому объекту.

Роли SQL позволяют объединить несколько привилегий в группу и предоставить как «пакет» индивидуальным пользователям. Отдельный пользователь может иметь привилегии от нескольких ролей, хотя только одна роль может быть выбрана при соединении с базой данных.

Рабочие режимы

Сервер Firebird может быть инсталлирован для выполнения в одном из трех рабочих режимов (operating modes): Суперсервер (Superserver), Классический сервер (Classic server) и Встраиваемый сервер (Embedded server). Различие между ними- скорее вопрос архитектуры. Любое клиентское приложение, написанное для соединения с Суперсервером, может соединяться точно тем же способом и с Классическим сервером и выполнять в точности те же задачи. Обратное также верно, за исключением того, что у Суперсервера более высокие требования к безопасности потоков для модулей внешних функций (определенные пользователем функции, библиотеки наборов символов, BLOB-фильтры).

Встраиваемый сервер является вариантом Суперсервера.

Классический сервер

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

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

! ! !

ПРИМЕЧАНИЕ. Классический сервер для Windows недоступен в версиях Firebird, предшествующих 1.5.

. ! .

Суперсервер

В 1996 году в предшественнике Firebird, InterBase 4.1 появился многопоточный Суперсервер для новых тогда 32-битных платформ Windows. Он позволял лучше использовать новые возможности серверов и компьютерных сетей. Возможности Суперсервера исключить взаимоблокировку поточных процессов и динамически выделять кэш-память сделали его более удобным, чем Классический сервер, когда велико количество пользователей, выполняющих чтение/запись, а системные ресурсы ограничены.

С бурным ростом операционных систем GNU/Linux на базе Intel к концу 1990-x годов Суперсервер стал хорошим решением для некоторых платформ POSIX. Основная структура Суперсервера для Linux была реализована в InterBase бета-версии 6.0 с открытыми исходными кодами и затем была полностью реализована в Firebird 1.0. Архитектура Суперсервера стала доступной для платформ Sun Solaris.

Встраиваемый сервер

Firebird 1.5 представил встроенный вариант Суперсервера для платформ Windows. В этой модели Суперсервер компилируется вместе с встроенным клиентом, который напрямую подключается к базе данных. Одна динамическая библиотека (fbembed.dll) использует межпроцессное коммуникационное пространство Windows для передачи клиентских запросов и ответов сервера. Его API идентичен API обычного Суперсервера или Классического сервера. В коде приложения не требуется ничего специального для использования встраиваемого сервера.

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

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

Сравнение моделей Суперсервера и Классического сервера см. в главе 36. В той же главе в разд. «Работа со встроенным сервером» вы найдете полное описание работы со встроенным сервером под Windows.

Пример базы данных

Везде в этой книге языковые примеры используют пример базы данных, которая находится в каталоге Examples в папке, где установлен Firebird. В дистрибутиве Firebird 1.0.x она называлась employee.gdb. В Firebird 1.5 это employee.fdb.

Краткое описание примера базы данных содержится в приложении 6.

Соглашения по документации

Основной текст книги представлен этим шрифтом.

Тексты, набранные данным шрифтом, являются кодом, скриптами или примерами командной строки.

! ! !

ПРИМЕЧАНИЕ. Фрагменты текста, выделенные как этот, — используются для того, чтобы привлечь ваше внимание к важным моментам, которые могут повлиять на ваше решение по использованию обсуждаемой возможности Firebird.

. ! .

! ! !

СОВЕТ. Фрагменты, выделенные как этот, содержат советы, блестящие идеи или рекомендации.

. ! .

! ! !

ВНИМАНИЕ! Обратите особое внимание на такой фрагмент.

. ! .

От изготовителя fb2.

I. К сожалению, выполнить вышеприведенные соглашения, в полном объеме, при изготовлении, варианта книги в формате fb2, не удалось.

II. Давайте, протестируем вашу читалку.

E=mc²

Если предыдущую строку вы видите в таком виде:

E=mc2

Значит, ваша читалка не поддерживает надстрочные символы (к сожалению, [пока] это бывает очень часто).

Для такого случая, в данном файле, я применяю следующие соглашения:

Пример надстрочных символов:

Теорема Ферма x(^n^) + y(^n^) = z(^n^)

Согласен, непривычно, неудобно, некрасиво…, но я выбрал такое оформление для удобства «везунчиков».

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

Порядок действий (алгоритм):

1. Распаковать данный файл(если это архив).

2. Открыть файл подходящим текстовым редактором (не сочтите за рекламу, я пользуюсь Notepad++)

3. Произведите 2 операции замены

“(^” на “<sup>”

“^)” на “</sup>”

(как вы догадываетесь, в запросе надо будет нажать кнопку «Заменить все»)

4. Сохраните файл, если хочется, сожмите в архив.

И будет вам счастье.

Ну, а нам, всем остальным, придется мучаться с тем, что есть…

III. Теперь, таблицы.

1 строка первого столбца	2 строка первого столбца	3 строка первого столбца
1 строка второго столбца	2 строка второго столбца	спорю, что не догадаетесь, какая это строка

Если вместо симпатичной таблицы вы увидели такое:

1 строка первого столбца

2 строка первого столбца

3 строка первого столбца

1 строка второго столбца

2 строка второго столбца

…

Значит ваша читалка таблиц не видит, что очень жаль, т.к. в книге их 197.

Что делать?… Ну, я поступаю так. В Mozilla Firefox поставил плагин для чтения fb2, и все вышесказанные проблемы решены, конечно, возможны и другие варианты…

IV. Еще одно огорчение:

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

Вот и все.

Успехов w_cat.

Синтаксические шаблоны

Некоторые фрагменты кода представляют синтаксические шаблоны (syntax patterns), то есть модели кода, которые демонстрируют обязательные и необязательные элементы синтаксиса операторов SQL или команд командной строки.

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

SELECT

[FIRST (m) ] [SKIP (n) ] [[ALL] | DISTINCT]

<список-столбцов> [, [ими столбца] | выражение | константа ]

AS имя-алиаса

FROM <таблица-или-процедура-или-просмотр>

[{[INNER] | [{LEFT | RIGHT | FULL} [OUTER]] JOIN}]

<таблица -или-процедура -или-просмотр>

ON <условия-соединения> [{JOIN..}]

[WHERE <условия-поиска>]

[GROUP BY <список-группируемых столбцов>]

[HAVING <условие-поиска>]

[OTIION <выражение-выбора> [ALL] ]

[PLAN <выражение-плана>]

[ORDER BY <список-столбцов>]

[FOR UPDATE [OF столбец1 [, столбец2. .]] [WITH LOCK]]

Специальные символы

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

Некоторые символы, которые никогда не появляются в операторах SQL или в командах командной строки, используются в синтаксических шаблонах для указания особых правил по их использованию. Это символы [],{}, |, <строка> и … (многоточие). Они используются в шаблонах следующим образом.

Квадратные скобки [ ] указывают, что элемент(n) в скобках являются необязательными. Когда встречаются вложенные квадратные скобки, то вложенные или внешние элементы являются необязательными.

Фигурные скобки { } указывают, что элементы внутри скобок являются обязательными. Обычное использование фигурных скобок — это представление необязательного элемента (заключенного в квадратные скобки), означающее: «Если необязательный элемент используется, часть, заключенная в фигурные скобки, является обязательной». В предыдущем примере, если используется необязательная явная фраза

JOIN,

[{[INNER] | [{LEFT | RIGHT | FULL} [OUTER]] JOIN}]

то внешняя пара фигурных скобок указывает, что ключевое слово JOIN является обязательным. Внутренняя пара фигурных скобок означает, что если задано соединение OUTER, то оно должно быть определено как LEFT, RIGHT или FULL С необязательным использованием ключевого слова OUTER.

Символ вертикальной черты | используется для разделения взаимоисключающих элементов. В предыдущем примере LEFT, RIGHT и FULL являются взаимоисключающими, также внутреннее (INNER) и внешнее (OUTER) соединения являются взаимоисключающими.

Параметры задаются строкой, которая заключается в угловые скобки < >. Например, [WHERE <условия-поиска>] указывает, что одно или более условий поиска требуется в качестве параметров для необязательного предложения WHERE В синтаксисе оператора SELECT.

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

<условия-поиска> = <выражение-столбца> = <константа> ( <выражение>

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

! ! !

ПРИМЕЧАНИЕ. Ни один из этих символов не является допустимым ни в операторах SQL, ни в командах командной строки^[1].

. ! .

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

ЧАСТЬ I. Учебный лагерь.

ГЛАВА 1. Инсталляция.

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

Удаленным клиентам не требуется сервер Firebird вовсе. Процедура инсталляции клиента Firebird несколько изменяется в зависимости от платформы (см. разд. «Инсталляция клиентов» в главе 7). Если вы в Firebird новичок, не пытайтесь устанавливать только клиента, пока не разберетесь, как все части инсталляции по умолчанию соответствуют друг другу.

Системные требования

Память на сервере (все платформы)

Оценка памяти сервера включает множество факторов.

* Работа сервера Firebird. Сервер Firebird осуществляет эффективное использование ресурсов сервера. Суперсервер (Superserver) после старта использует приблизительно 2 Мбайта памяти. Классический сервер (Classic server) в POSIX не использует памяти, пока не установлено клиентское соединение. В Windows небольшие сервисы прослушивают запросы на соединения.

* Клиентские соединения. Каждое соединение с Суперсервером добавляет приблизительно 115 Кбайт, больше или меньше, в соответствии со стилем и характеристиками клиентских приложений, а также спроектированной схемой базы данных. Каждое соединение с Классическим сервером использует приблизительно 2 Мбайта (в зависимости от количества применяемых соединением таблиц, триггеров, процедур и других объектов — может быть и до 30-40 Мбайт. Для баз данных среднего размера — от 4 до 15 Мбайт).

* Кэш базы данных. Значение по умолчанию может конфигурироваться — в страницах базы данных. Суперсервер использует единый кэш (с размером по умолчанию 2048 страниц) для всех соединений и автоматически увеличивает кэш при необходимости. Классический сервер создает индивидуальный кэш (по умолчанию 75 страниц) на каждое соединение.

На основании существующих оценок отводите 64 Мбайта RAM для сервера и 16 Мбайт для локального клиента. Чем больше клиентов вы добавляете, тем больше памяти будет использовано. Базы данных с большим размером страниц используют ресурсы из большего участка памяти, чем базы данных с меньшим размером страниц. Использование ресурсов для Классического сервера увеличивается линейно с каждым новым подключением клиента; для Суперсервера ресурсы разделяются между несколькими подключениями, и будут динамически увеличиваться при необходимости. Firebird 1.5 будет использовать для сортировки, если она необходима, дополнительную RAM. Использование памяти более подробно обсуждается в главе 6.

Инсталляционные диски

Сервер Firebird — и любые базы данных, которые вы создаете или с которыми соединяетесь, — должны находиться на жестком диске, который физически подключен к машине. Вы не можете разместить компоненты сервера или любой базы данных на назначенном диске, в разделяемой файловой системе или в сетевой файловой системе.

CD-ROM

Вы не можете запускать сервер Firebird с CD-ROM. При этом вы можете соединяться с базой данных только для чтения, находящейся на устройстве CD-ROM, физически подключенным к серверу^[2].

Дисковое пространство

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

* Сервер. Минимальная инсталляция сервера требует дискового пространства в пределах от 9 до 12 Мбайт в зависимости от платформы и архитектуры.

* Клиентская библиотека. Требует 350 Кбайт (встроенная: 1.4-2 Мбайт).

* Инструменты командной строки. Требуют приблизительно 900 Кбайт.

* Утилиты администратора базы данных. Требуют 1-6 Мбайт в зависимости от выбранных утилит. См. список свободно распространяемых и коммерческих утилит в приложении 5.

Минимальные требования к машине

Минимальные требования зависят от того, как вы планируете использовать систему. Вы можете запустить сервер и разрабатывать схемы баз данных на персональном компьютере с минимальной конфигурацией- даже на «быстром» 486 или на Pentium II с 64 Мбайт RAM будет работать Firebird 1.0.x- но такая конфигурация не позволит использовать многие возможности при работе в сети. Для версии 1.5 и более поздних процессор 586 с 128 Мбайт RAM может рассматриваться как минимум. Windows более требовательна к CPU и оперативной памяти, чем Linux, в которой запускается сервер на консольном уровне. Версии операционной системы влияют на требования: некоторые платформы UNIX требуют больше ресурсов как для сервера, так и для клиента, а требования некоторых версий Windows неприменимы к указанным характеристикам, независимо от требований программного обеспечения.

Поддержка SMP и HyperThreading

Суперсервер и Классический сервер Firebird могут использовать разделяемую память мультипроцессоров в Linux. В Windows поддержка SMP (симметричный мультипроцессор) доступна только для Классического сервера.

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

Характеристики процессора могут быть сконфигурированы на уровне сервера в firebird.config (версия 1.5) или в ibconfig/isc config (версия 1.0.x). В Windows для Суперсервера версий 1.0.x и 1.5 маска свойств CPU должна быть установлена в «единственный CPU» для SMP-машины. (См. разд. «Файл конфигурации Firebird» в главе 36.)

Операционная система

В табл. 1.1 показаны минимальные требования к операционной системе для выполнения серверов Firebird. При этом всегда смотрите файл README в каталоге /doc в вашем комплекте поставки для получения последней информации по операционной системе.

Таблица 1.1. Минимальные требования Firebird к операционной системе

Операционная система	Версия	Примечания
Microsoft	Windows NT 4.0	Требуется Service Pack 6а
	Windows 95/98/ME	Возможно, нужны обновления: библиотеки времени выполнения Microsoft С (msvcrt.dll) версии 6 или выше. Для Firebird 1.5 требуется библиотека C++ (msvcrt60.dll или выше). В Firebird 1.5 копии располагаются в каталоге bin каталога Firebird. Winsock 2 требуется для всех серверов; он может быть нужен для инсталляции под Windows 95
	Windows 2000 с Service Pack 2
	Windows XP	Базы данных не должны иметь расширения gdb
	Server 2003	Базы данных должны располагаться в разделах, где возможность VSS (оперативное копирование тома) отключена
Linux	Red Hat	Версия 7.1 или выше для Firebird 1.0.x, версия 8.0 или выше для Firebird 1.5. Для Red Hat 9 и выше обратитесь к замечаниям по инсталляции Linux в соответствии с реализацией NPTL
	SuSE	Версия 7.2 или выше для Firebird 1.0.x, версия 8.10 или выше для Firebird 1.5
	Mandrake	Версия 8.0 или выше для Firebird 1,0.x, версия 9.0 или выше для Firebird 1.5
	Все платформы Linux	Firebird 1.5 (сервер и клиент) требует glibc-2.2.5 или выше и libstdc++.so, связанную с libstdc++-5.0 или выше
Другие ОС	Solaris (Intel, SPARC), Mac OS X, FreeBSD, HP-UX 10+	Подробности смотрите в комплекте поставки Firebird

Как получить инсталляционный комплект

Комплект Firebird можно найти на главном сайте Firebird (http://www.firebirdsql.org) или на сайте SourceForge (http://firebird.sourceforge.net). Ссылки на этих страницах приведут вас к: http://sourceforge.net/project/showfiles.php?group_id=9028.

Главная страница на сайте Firebird обычно содержит список ссылок на последние релизы для Linux и Windows. Другие ссылки будут указывать на дистрибутивы для других платформ. Если файл в

своем имени содержит «src», то это созданный исходный код, а не инсталляционный пакет. Дистрибутивы, имеющие в своем имени «debug», «debuginfo» или «pdb», содержат специальные файлы для анализа и отладки сбоев сервера или клиента с помощью сред разработки и не требуются для обычной работы.

Содержание комплекта

Каждый инсталляционный комплект содержит все компоненты, нужные для инсталляции Firebird.

* Исполняемая программа сервера Firebird.

* Множество других программ, нужных при инсталляции и/или во время выполнения задач.

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

* Файл безопасности баз данных (isc4.gdb для версии 1.0.x; security.fdb для версии 1.5).

* Одна или более версий клиентской библиотеки для установки на сервере и на клиентской рабочей станции.

* Инструменты командной строки.

* Стандартные библиотеки внешних функций и скрипты их описания (*.sql).

* Пример базы данных.

* Заголовочные файлы С (не нужны начинающим!).

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

* Заметки по релизу и различные файлы README (необходимы для прочтения).

Соглашения по именованию в комплекте инсталляции

Имена файлов комплекта поставки для разных платформ не являются одинаковыми. Увы, они даже не являются «последовательно неодинаковыми»; при создании дистрибутива часто нужно приспосабливаться к специфическим для платформы соглашениям или просто следовать их собственным правилам. Тем не менее некоторые элементы в именах файлов могут быть вам полезны для идентификации того комплекта, который вам нужен.

Классический сервер или Суперсервер?

Обычно первой частью имени является строка «Firebird».

* Если релиз для Windows поддерживает Классический сервер, он будет включен в тот же инсталлятор, что и Суперсервер.

* Для платформ POSIX, которые поддерживают обе архитектуры, отдельные инсталляторы поставляются для Классического сервера и Суперсервера. Имя установочного пакета будет начинаться с «FirebirdCS» (для Классического сервера) или с «FirebirdSS» (для Суперсервера).

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

Номера версий

Имена всех комплектов поставки должны содержать разделенную точками строку чисел в следующем порядке: номер версии, номер релиза, номер подрелиза. Например, «1.0.3»- это третий подрелиз от начального (код С) релиза Firebird версии 1, в то время как «1.5.0» — начальный подрелиз релиза 5 (код C++) версии 1. Большинство комплектов поставки также содержат абсолютный номер создания (например, 1.0.3.972 или 1.5.2.4731). Для некоторых малых платформ, особенно тех, которые имеют собственные правила именования и созданы различными компиляторами, номера версий могут быть менее очевидными.

64-битовый ввод/вывод

Для платформ, которые требуют специальной компоновки для поддержки 64-битового ввода/вывода, вам нужно посмотреть на инфикс «6410» где-нибудь в строке имени. Он не будет присутствовать в именах комплектов поставки для операционных систем, которые осуществляют автоматическую поддержку 64-битового ввода/вывода.

Не пытайтесь инсталлировать комплект, отмеченный как «6410», на версии, где ОС, файловая система или аппаратура не поддерживают 64-битовый ввод/вывод^[3].

Архитектура CPU

Архитектура CPU обычно включается в имя строки инсталляционного комплекта. Например, инсталлятор RPM для UNIX обычно включает указание на набор микросхем (например, i686). Список файлов отображает в списке загрузки обычно наиболее полезный указатель минимального набора микросхем, поддерживаемого инсталляционным пакетом. Комплект для Solaris предполагает наличие процессора Intel, если в имени комплекта поставки не присутствует «SPARC».

Зеркальные сайты

Когда вы найдете требуемый комплект поставки, щелкните мышью по гиперссылке — имени файла. Вы перейдете на список зеркальных сайтов, как показано на рис. 1.1.

Не имеет значения, какой зеркальный сайт вы выберете — комплект поставки идентичен для всех сайтов.

Комплект поставки для Linux

Прокручивайте отображаемый в SourceForge список файлов, пока не увидите файлы, показанные на рис. 1.2.

Здесь представлены реальные исполняемые инсталляторы. Доступны инсталляторы RPM и инсталляторы сжатых файлов (TAR-файлы). Если ваш дистрибутив Linux поддерживает инсталляторы RPM, выберите именно его. Он создаст каталоги и установит все необходимое, определит пароль для пользователя SYSDBA и запустит выбранный вами сервер. Инсталляторы имеют следующие имена:

* Firebird 1.5 — FirebirdCS-1.5.2.4731-0.i686.rpm (Классический) и FirebirdSS-1.5.2.4731-0.i686.rpm (Суперсервер);

* Firebird 1.03 — FirebirdCS-1.0.0.972-0.i386.rpm (Классический) и FirebirdSS-1.0.0.972-0.i386.rpm (Суперсервер).

Посмотрите документацию соответствующей платформы по использованию Red Hat Package Manager (RPM). В большинстве дистрибутивов у вас есть возможность запускать инсталлятор RPM из командной строки или через графический интерфейс пользователя (GUI).

Рис. 1.1. Выбор зеркального сайта SourceForge

Рис. 1.2. Комплект поставки для Linux на SourceForge

Сжатые файлы (tarballs)

В дистрибутивах Linux, которые не могут выполнять пакеты RPM, и во многих разновидностях UNIX используйте сжатые файлы (обычно .tar.gz или .bz2), т. к. они дают опытному пользователю Linux больший контроль над процессом инсталляции. Соответствующая утилита распаковки понадобится на вашем сервере для распаковки комплекта поставки в вашей файловой системе. Вы найдете детальные инструкции в официальных замечаниях по релизу, README-файлах и замечаниях к поставке. Знающие пользователи могут также просмотреть и настроить инсталляционные скрипты, чтобы сделать их работоспособными в менее общих версиях Linux.

! ! !

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

. ! .

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

! ! !

СОВЕТ. Если вы не нашли замечания по релизу в вашем комплекте поставки, обратитесь к главной странице сайта IBPhoenix (http://www.ibphoenix.com) и загрузите замечания по релизу оттуда.

. ! .

Реализация NPTL для высших версий Linux

Новая библиотека потоков POSIX (Native POSIX Thread Library, NPTL) в Red Hat 9 (и, возможно, в более поздних дистрибутивах Linux) создает проблемы с Суперсервером и локально скомпилированными программами, а также с утилитами. Утилита gbak сообщает об ошибке «broken pipe». Для устранения этой ошибки выполните следующие шаги:

1. Проверьте, что запущен сервер. В /etc/init.d/firebird выполните:

LD_ASSUME_KERNEL-2.2.5

export LD_AS SOME_KERNEL

2. Вам нужно установить переменную окружения в соответствии с локальным окружением, так что добавьте следующее в /etc/profile, чтобы быть уверенным, что каждый пользователь может ее использовать в утилитах командной строки. После

HISTSIZE=1000

добавьте

LD_ASSUME_KERNEL=2.2.5

С помощью следующей строки экспортируйте ее:

export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE INPUT_RC LD_ASSUME_KERNEL

Комплект поставки для Windows

Официальный комплект поставки для Windows (рис. 1.3) распространяется в виде исполняемых инсталляторов. Очень рекомендуется использовать инсталлятор в вариантах ZIP или RAR.

Рис. 1.3. Комплект поставки Windows с сайта SourceForge

Комплекты поставки Firebird включают исполняемые программы и связанные файлы для двух моделей сервера: Суперсервер и Классический сервер. В диалогах инсталлятора вас будут спрашивать, какую модель вы хотите устанавливать, какие компоненты не должны копироваться на диск. Единственная поддерживаемая модель для Firebird 1,0.x — это Суперсервер.

Имена релизов инсталляторов следующие:

* Firebird 1.5 — Firebird-1.5.2.473l_Win32.exe;

* Firebird 1.03 — Firebird-1.0.3.972-Win32.exe.

Сжатые файлы

Если комплект поставки для Windows содержит ZIP-файлы, вам нужно иметь утилиты (например, WinZip, PKZip или WinRAR) для просмотра содержимого и/или распаковки файлов перед инсталляцией. Такой комплект поставки (не для начинающих) содержит следующее:

* версия 1.5 ZIP полной поставки клиент-сервер Firebird-1.5.2.473l_win32.zip. Может быть распакован в стандартный каталог без инсталляции в системе. Некоторые программы инсталляции должны запускаться после распаковки. Инструкции включены в различные текстовые файлы в подкаталоге /doc;

* отдельный комплект поставки встраиваемого сервера версии 1.5 для Windows. Имя файла релиза комплекта поставки — Firebird-1.5.2.4731_embed_win32.zip.

! ! !

ПРИМЕЧАНИЕ. Не существует встраиваемого сервера для версии 1.0.x.

. ! .

Серверы

На платформах, имеющих сервисы — Windows NT, 2000 и XP — сервер Firebird инсталлируется по умолчанию для запуска как сервис. Сервис инсталлируется и запускается автоматически по окончании процедуры инсталляции, а также при первоначальной загрузке серверной машины. Как остановить и запустить сервер вручную см. главу 4.

Младшие из платформ Windows — Windows 95, 98 и ME — не поддерживают сервисы. После инсталляции сервер Firebird будет запускаться как приложение, защищенное программой Guardian. Если приложение сервера будет по разным причинам аварийно завершено, Guardian постарается заново запустить его. Для сервера, запущенного как сервис, рекомендуется также использовать Guardian.

Не пытайтесь инсталлировать Классический сервер, если у вас уже установлен Суперсервер, или наоборот.

Клиентские библиотеки

Копии клиентских библиотек устанавливаются:

* для Firebird 1.0.x имя клиентской библиотеки gds32.dll; она устанавливается в системный каталог C:WINNTsystem32 для Windows, имеющей сервисы, и в C:Windows для других версий Windows;

* для Firebird 1.5 и последующих версий имя клиентской библиотеки fbclient.dll; по умолчанию она устанавливается в каталог /bin корневого каталога Firebird. По умолчанию утилиты загружают ее именно оттуда, а не из системного каталога.

! ! !

ПРИМЕЧАНИЕ. Для обычных клиентских приложений, включающих множество компонентов базы данных и инструменты администратора, размещение и именование клиентской библиотеки не являются столь строгими. См. в главе 7 альтернативные варианты инсталляции клиентской библиотеки — на сервере и на клиентских рабочих станциях — для совместимости со многими графическими инструментами и другими существующими приложениями.

. ! .

Тестирование результатов инсталляции

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

Сетевой протокол

Предполагается, что вы будете использовать рекомендованный протокол TCP/IP для вашей сети клиент-сервер, чтобы получить все преимущества независимой от платформы сети.

! ! !

СОВЕТ. Чтобы получить информацию об использовании протокола NetBEUI (Named Pipes, Именованные каналы) во всех версиях Windows, см. разд. «Сетевые протоколы» в главе 2.

. ! .

! ! !

ВНИМАНИЕ! Firebird не поддерживает IPX/SPX и не работает на Novel Netware 3 и 4.

. ! .

Тестирование сервера

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

ping 192.13.14.1

Замените в этом примере IP-адрес на реальный IP-адрес вашего сервера.

! ! !

СОВЕТ. Если вы получили сообщение об истечении времени ожидания, обратитесь к главе 2 и приложению 2 для дальнейших инструкций. Если вам нужна более подробная информация об установках серверных IP-адресов, см. разд. «Сетевой адрес для сервера» в главе 2.

. ! .

Если вы соединяетесь с сервером с локального клиента — т. е. клиент запущен на той же машине, что и сервер, — вы можете обратиться к виртуальной заглушке TCP/IP:

ping localhost

ИЛИ

ping 127.0.0.1

Проверка, что сервер Firebird запущен

Классический сервер POSIX

Используйте команду ps в командной строке для просмотра запущенных процессов. Если какие-нибудь клиенты соединены с классическим процессом Firebird, вы должны увидеть один процесс с именем fb_netserver (или gds_inet_server для Firebird 1.0.x) для каждого соединенного клиента. Команда ps имеет несколько переключателей, однако следующий вариант дает подходящий список. Команда grep фильтрует вывод так, что вы будете видеть только процессы Firebird.

[xxx]$ ps -aux | grep fb

На рис. 1.4 запущены три клиентских процесса.

Рис. 1.4. Список классических процессов, полученный с помощью ps

Суперсервер POSIX

Поскольку Суперсервер разветвляется на потоки для каждого соединения, будет интересным задать переключатель -f [ork] среди других переключателей для отображения его процессов и потоков. Вы получите форматированное отображение разветвленных процессов, похожее на представленное на рис. 1.5:

[xxx]$ ps -auxf | grep fb

Рис. 1.5. Список процессов и потоков Суперсервера, полученный с помощью ps

Та же команда ps должна отображать один процесс с именем fbguard (или ibguard), если сервер был запущен с переключателем -f[orever], и один главный процесс с именем fbserver (или ibserver). Должен быть, по меньшей мере, один дочерний поток с именем fbserver (или ibserver), разделенный на несколько потоков. Эта первая группа является «выполняющимся сервером» без клиентских соединений, за исключением тех, которые использует сервер для прослушивания портов и сборки мусора. Далее будет группа потоков для каждого соединения.

! ! !

ПРИМЕЧАНИЕ. Префикс «fb» относится к Firebird 1.5, a «gdb» и «ib»- к Firebird 1.0.x. Используйте ps -aux | grep gds, если у вас запущена версия 1.0.x.

. ! .

Windows NT 4, 2000 и XP

Для серверных платформ Windows запустите апплет Firebird Server Control с Панели управления (Control Panel).

Апплет Server Control

На рис. 1.6 показан апплет Firebird Server Control, запущенный под Windows 2000 Server. Если вы использовали инсталлятор, этот апплет будет установлен на вашу Панель управления. Его внешний вид может изменяться в зависимости от варианта сервера Windows.

Рис. 1.6. Апплет Firebird Server Control

Вы можете использовать этот апплет для запуска и остановки сервиса и для модификации режимов запуска и выполнения. Не рекомендуется изменять режим на Run as an application (Выполнять как приложение) для многопользовательского использования в целях безопасности — вы должны оставлять подключение к серверу, чтобы сервер Firebird оставался запущенным.

Апплет Service

Если у вас нет апплета Control Panel, вы можете использовать апплет Services (рис. 1.7) в Инструментах администрирования. В Windows NT 4 вы можете получить доступ к этому апплету напрямую через Панель управления.

Рис. 1.7. Апплет Services на серверных платформах Windows

На рис. 1.7 показаны имена сервисов Firebird 1.5- для Guardian и сервера. Имена сервисов могут отличаться в зависимости от версий, Guardian может вовсе не появляться в списке. Пользователь с привилегиями администратора может, щелкнув правой кнопкой мыши по имени сервиса, остановить или запустить сервис. Если вы используете Guardian, остановите этот сервис, чтобы остановить и Guardian, и сервер.

В Windows 2000 и Windows Server 2003 Guardian скорее удобен, чем необходим, поскольку эти две операционные системы имеют средства просмотра и повторного запуска сервисов. Рекомендуется оставлять Guardian активным на других платформах, если пользователь SYSDBA недоступен для рестарта сервера вручную в случаях, когда он был остановлен по различным причинам.

Другие апплеты Панели управления

Если вам нужен апплет Firebird Manager и вы не нашли его инсталлированным на Панели управления вашего сервера Windows, или если вам нужен апплет с языком, отличным от английского, загрузите его с сайта Firebird: http://www.ibphoenix.com. Закройте окно Панели управления и скопируйте файл CPL непосредственно в ваш системный каталог Windows.

Windows 9х, ME и XP Home Edition

Windows 9х, ME и XP Ноте Edition не поддерживают сервисы. Сервер Firebird должен быть запущен как приложение, контролируемое программой Guardian. Если вы используете инсталляционный комплект, который устанавливает, но не запускает автоматически Guardian и сервер Firebird, вы можете сделать это вручную, как показано далее.

1. Найдите исполняемый файл программы Guardian (ibguard.exe) и создайте для него ярлык в области запуска меню кнопки Пуск.

2. Откройте диалоговое окно Свойства для этого ярлыка и перейдите к полю, где располагается командная строка.

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

fbguard.exe -a

4. Сохраните и закройте диалог Свойства.

5. Сделайте двойной щелчок по ярлыку для запуска Guardian. Guardian запустит fbserver.exe.

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

Апплет Server Control

Некоторые версии апплета Server Control могут быть установлены на платформе Windows, не поддерживающей сервисы. Если инсталлятор устанавливает его на вашей машине, то он может быть использован так же, как было описано для версий, поддерживающих сервисы. Невозможно только выбрать вариант Run as a service (Запускать как сервис), даже если он отображается на экране. В Windows версии Ноше, чтобы исключить путаницу, апплеты бывают скрытыми или отображаются недоступными (серым цветом).

Инсталляция встраиваемого сервера

! ! !

ВНИМАНИЕ! Если вы раньше не использовали Firebird, то очень рекомендуется пропустить этот вариант, пока вы не приобретете опыт работы с сервером Firebird и «регулярными» клиентами. Вы ничего не потеряете, разрабатывая ваши первые приложения в обычной модели клиент-сервер; они будут работать так же хорошо и с встраиваемым сервером.

. ! .

Объединение сервера и клиента осуществляется через динамическую библиотеку fbembeded.dll, которую вы найдете в каталоге /bin после обычной инсталляции Firebird. Вы можете инсталлировать встраиваемый сервер, если вы уже инсталлировали сервер или другие встраиваемые серверы.

Для каждого приложения встраиваемого сервера каталог исполняемого файла вашего приложения становится корневым каталогом этого приложения встраиваемого сервера. Для выполнения встроенной инсталляции с вашим приложением сделайте следующее:

* скопируйте fbembeded.dll в каталог приложения и переименуйте в fbclient.dll или в gds32.dll в соответствии с тем, какое имя клиентского файла требуется вашей программе связи с базой данных;

* скопируйте файлы firebird.msg, firebird.conf и aliases.conf в тот же каталог;

* если вы собираетесь использовать алиасы базы данных (рекомендуется), то скопируйте aliases.conf в каталог приложения (домашний каталог, home directory) и сконфигурируйте его для этого конкретного приложения;

* если внешние библиотеки требуются для вашего приложения, такие как поддержка интернациональных языков (fbintl.dll), библиотеки UDF или библиотеки Blob — фильтров, создайте для них соответствующие каталоги (../intl, ../UDF) непосредственно внутри каталога вашего приложения и скопируйте туда эти файлы.

Пример структуры встроенной инсталляции

Приведем пример структуры каталогов и содержание файлов конфигурации для инсталлированного приложения встраиваемого сервера:

D:my_appMyApp.exe

D:my_appgds32.dll

D:my_appfbfirebird.conf

D:my_appfbaliases.conf

D:my_appfbfirebird.msg

D:my_appfbintlfbintl.dll

D:my_appfbUDFfbudf.dll

Файл firebird.conf:

RootDirectory = D:my_appfb

Файл aliases.conf:

MyApplication = D:databasesMyDB.fdb

Другие вещи, которые вам нужно знать

Пользователи

Имя пользователя и пароль по умолчанию

Пользователь SYSDBA имеет все привилегии доступа к серверу. Программа инсталляции создаст пользователя SYSDBA в базе данных безопасности (security.fdb).

Для версий под Windows и версии 1.0.x под Linux пароль masterkey.

! ! !

СОВЕТ. Фактически пароль — masterke, т. к. все символы после восьмого игнорируются.

. ! .

В версии 1.5 и более поздних под Linux инсталлятор в процессе установки генерирует случайный пароль, помещает его в базу данных безопасности и сохраняет в текстовом файле SYSDBA.password. Запомните этот пароль или используйте для доступа к базе данных безопасности, чтобы изменить его на что-нибудь более простое для запоминания.

! ! !

ВНИМАНИЕ! Если ваш сервер совсем не защищен в Интернете, вы должны изменить этот пароль немедленно.

. ! .

Как изменить пароль пользователя SYSDBA

Если вы работаете в Linux или другой системе, которая может выполнять SH- скрипты, измените текущий каталог на ../bin в вашем каталоге инсталляции и найдите скрипт с именем changeDBAPassword.sh. Все, что вам нужно сделать, — это запустить скрипт и ответить на подсказки. Когда вы в первый раз запустите скрипт, вам будет нужно ввести пароль, который инсталлятор записал в файл SYSDBA.password; он находится в корневом каталоге Firebird:

[bin]# sh changeDBAPassword.sh

ИЛИ

[bin]# ./changeDBAPassword.sh

Прямое использование gsec

Следующая процедура будет работать под Windows и Linux. В Linux, чтобы запустить gsec, вы должны войти в операционную систему как суперпользователь (root). Пусть вы решили изменить у SYSDBA пароль с masterkey на icuryy4me (в Firebird 1.5 для Linux инсталлированный пароль не masterkey, он может оказаться совсем невразумительным!). Вам нужно выполнить следующие шаги:

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

2. Для Windows наберите следующее, рассматривая символы, как чувствительные к регистру:

gsec -user sysdba -password masterkey

Для платформ POSIX наберите:

./gsec -user sysdba -password masterkey

Теперь вы должны увидеть подсказку утилиты gsec:

GSEC>

3. Наберите команду:

GSEC> modify sysdba -pw icuryy4me

4. Нажмите клавишу <Enter>. Новый пароль icuryy4me будет зашифрован и сохранен, a masterkey не будет больше действовать.

5. Теперь завершите программу gsec:

GSEC> quit

Поскольку Firebird игнорирует все символы в пароле после восьмого, icuryy4m будет работать так же, как и icuryy4monkey.

! ! !

СОВЕТ. Полные инструкции по использованию gsec находятся в главе 34.

. ! .

Пользователи и группы в Linux/UNIX

Начиная с Firebird 1.5, пользователь root больше не является пользователем по умолчанию, который может запускать сервер. Это означает, что вам нужно поместить пользователей, не являющихся root, в группу firebird, чтобы предоставить им возможность доступа к базам данных.

Чтобы добавить пользователя (например, sparky) в группу firebird, пользователю root нужно ввести:

$ usermod -G firebird sparky

Теперь sparky может соединиться с базой данных Firebird и начать работу с ней.

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

$ groups

! ! !

СОВЕТ. Пользователю группы firebird могут также понадобиться привилегии чтения и записи ко всем базам данных и привилегии чтения, записи и выполнения ко всем каталогам, где размещаются базы данных.

. ! .

Инструмент администратора

Инсталляционный комплект Firebird не содержит инструментов администратора с графическим интерфейсом. У него есть набор инструментов командной строки (исполняемые программы), которые расположены в каталоге /bin каталога инсталляции Firebird. Их использование подробно описано в части IX.

Отличные инструменты графического интерфейса, доступные для использования на клиентских машинах Windows, слишком многочисленны, чтобы их здесь описать. Небольшое количество графических инструментов написано на Borland Kylix для использования на клиентских машинах под Linux, они находятся на разных стадиях завершения.

Список наиболее известных инструментов администратора для Firebird представлен в приложении 5. Для получения самого последнего списка зайдите на http://www.ibphoenix.com, выберите ссылку Contributed из области загрузки и нажмите на ссылку Administration Tools.

! ! !

СОВЕТ. Вы можете использовать клиентские инструменты администратора в Windows для доступа к серверу Linux и наоборот.

. ! .

Размещение на диске по умолчанию

Таблицы в этом разделе описывают размещение компонентов для Windows и Linux на диске по умолчанию. Информация дается в контексте двух версий:

* версии, предшествующие Firebird 1.5;

* версии Firebird 1.5 и последующие.

Разница является существенной. Версии, предшествующие Firebird 1.5, используют размещение, имена компонентов и ссылки на ресурсы, как и InterBase 6.x и более ранние версии InterBase. Следовательно, не существует возможности запускать и сервер Firebird, и сервер InterBase этих версий на одной и той же машине.

В пересмотре основного кода, который начался с версии 1.5, старые ссылки на постороннюю информацию InterBase были удалены, а многие из главных компонентов были переименованы. Firebird 1.5 дает возможность запускать также и сервер InterBase. Это верно и для Firebird 2.

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

Таблица 1.2. Инсталляция Firebird 1.5 для Linux и некоторых платформ UNIX

Компонент	Имя файла	Размещение по умолчанию
Классический сервер	fb_inet_server	/opt/firebird/bin
Программа Lock Manager (только Классический сервер)	fb_lock_mgr	/opt/firebird/bin
Встроенный клиент для Классического сервера	libfbembed.so. 1.5.0	/opt/lib
Firebird Guardian (только Суперсервер)	fbguard	/opt/firebird/bin
Суперсервер	fbserver.exe	/opt/firebird/bin
Поточный клиент для Суперсервера и Классического сервера	libfbclient.so	/usr/lib
Файл конфигурации	firebird.conf	/opt/firebird
Файл алиасов базы данных	aliases.conf	/opt/firebird
Файл сообщений	firebird.msg	/opt/firebird
Файл сгенерированного пароля	SYSDBA.password	/opt/firebird
База данных безопасности	security.fdb	/opt/firebird
Копия базы данных безопасности	security.fbk	/opt/firebird
Инструменты командной строки	isql, gbak, gfix, gstat, gsec, gdef, gpre, qli	/opt/firebird/bin
Инструмент сервера (только Суперсервер)	fbmgr	/opt/firebird/bin
Скрипты командной строки	Различные; обратитесь к файлам README и заметкам по релизу	/opt/firebird/bin
Скрипт шаблона для Firebird (только Классический сервер)	firebird.xinetd	/opt/firebird/misc
Библиотеки внешних функций (библиотеки UDF)	ib_udf.so, fbudf.so	/opt/firebird/UDF
Библиотека утилиты памяти (используется в ib_udf)	libib util.so	/opt/firebird/lib
Скрипты DDL для библиотек внешних функций	ib_udf.sql, fbudf.sql	/opt/firebird/UDF
Библиотека поддержки интернациональных языков	fbintl	/opt/fire b ird/i nt!
Заметки по релизу	Firebird_v15.nnn_ ReleaseNotes.pdf	/opt/firebird
Другая документация	Файлы README no различным темам	/opt/firebird/doc
Пример базы данных	employee.fdb	/opt/firebird/sample
Заголовочные файлы С	ibase.h, iberror.h и др.	opt/firebird/include

Таблица 1.3. Инсталляция Firebird 1.5 для 32-битовых платформ Windows

Компонент	Имя файла	Размещение по умолчанию
Классический сервер	fb_inet_server.exe	C:Program FiiesFirebird Firebird_1_5bin
Программа Lock Manager (только Классический сервер)	fb_lock_mgr.exe	C:Program FilesFirebird Firebird_1_5bin
Firebird Guardian (только Суперсервер)	fbguard.exe	C:Program FilesFirebird Firebird_1_5bin
Суперсервер	fbserver.exe	C:Program FilesFirebird Firebird_1_5bin
Встроенный Суперсервер	fbembed.dll	C:Program FilesFirebird Firebird_1_5bin (инсталлировать в каталог приложения и переименовать в fbciient.dll)
Клиентская библиотека для Суперсервера и Классического сервера	gds32,dll (заглушка) и fbclient.dll	C:Program FilesFirebirdFirebird_1_5bin
Файл конфигурации	firebird.conf	— // —
Файл алиасов базы данных	aliases.conf	— // —
Файл сообщений	firebird.msg	— // —
База данных безопасности	security.fdb	— // —
Копия базы данных безопасности	security.fbk	— // —
Инструменты командной строки	isql, gbak, gfix, gstat, gsec, gdef, gpre, qli, fb_lock_print	— // —
Сервисы и регистрационные инструменты	instsvc.exe, instreg,exe	— // —
Библиотеки внешних функций (библиотеки UDF)	ib_udf,dll, fbudf,dll	C:Program FilesFirebirdFirebird_1_5UDF
Библиотека утилиты памяти (используется в ib_udf,dll)	ib_util.dll	C:Program FilesFirebirdFirebird_1_5bin
Скрипты DDL для библиотек внешних функций	ib_udf,sql, fbudf,sql	C:Program FilesFirebirdFirebird_1_5UDF
Библиотека поддержки интернациональных языков	fbintl,dll	C:Program FilesFirebirdFirebird_1_5intl
Заметки по релизу	Firebird_v15.nnn_ ReleaseNotes.pdf	C:Program FilesFirebirdFirebird_1_5
Другая документация	Файлы README по различным темам	C:Program FilesFirebirdFirebird_1_5doc
Пример базы данных	employee.fdb	C:Program FilesFirebirdFirebird_1_5sample
Заголовочные файлы С	ibase.h, iberror.h и др.	C:Program FilesFirebirdFirebird_1_5include

Таблица 1.4. Инсталляция Firebird 1.0.3 для Linux и некоторых платформ UNIX

Компонент	Имя файла	Размещение по умолчанию
Классический сервер	gds_inet_server	/opt/interbase/bin
Программа Lock Manager (только Классический сервер)	ib_lock_mgr	— // —
Встроенный клиент для Классического сервера	gdslib.so	/usr/lib
Суперсервер	ibserver.exe	/opt/interbase/bin
Поточный клиент для Суперсервера и Классического сервера	gdslib.so	/usr/lib
Файл конфигурации	isc_config	/opt/interbase
Файл сообщений	interbase.msg	— // —
База данных безопасности	isc4.gdb	— // —
Копия базы данных безопасности	isc4.gbk	— // —
Инструменты командной строки	isql, gbak, gfix, gstat, gsec, gdef, gpre, qli	/opt/interbase/bin
Инструмент сервера (только Суперсервер)	fbmgr	— // —
Скрипты командной строки	Различные; обратитесь к файлам README и замечаниям по релизу	/opt/interbase/bin или /opt/interbase/sample
Скрипт шаблона для Firebird (только Классический сервер)	firebird.xinetd	— // —
Библиотеки внешних функций (библиотеки UDF)	ib_udf,so, fbudf,so	/opt/interbase/udf
Библиотека утилиты памяти (используется в ib_udf) ~TSROr	libib_util,so	/opt/interbase/udf ~TSR/ort/interbase
Скрипты DDL для библиотек внешних функций	ib_udf.sql	/opt/interbase/udf
Библиотека поддержки интернациональных языков	intl или intl.so	/opt/interbase/intl
Пример базы данных	employee.fdb	/opt/interbase/sample
Заголовочные файлы С	ibase.h, iberror.h и др.	/opt/interbase/include

Таблица 1.5. Инсталляция Firebird 1.0.3 для 32-битовых платформ Windows

Компонент	Имя файла	Размещение по умолчанию
Firebird Guardian	ibguard.exe	C:Program FilesFirebirdbin
Суперсервер	ibserver.exe	— // —
Клиентская библиотека	gds32.dll	— // —
С:WINNTsystеm32 (платформа с сервисами) или C:Windows (другие)	gds32.dll	CAWINNTsystem32 (платформа с сервисами) или CAWindows (другие)
Файл конфигурации	ibconfig	C:Program FilesFirebird
Файл сообщений	interbase.msg	C:Program FilesFirebird
База данных безопасности	isc4.gdb	C:Program FilesFirebird
Копия базы данных безопасности	isc4.gbk	C:Program FilesFirebird
Инструменты командной строки	isql, gbak, gfix, gstat, gsec, gdef, gpre. qli, iblockpr	C:Program FilesFirebirdbin
Сервисы и регистрационные инструменты	instsvc.exe, instreg.exe	C:Program FilesFirebirdbin
Библиотеки внешних функций (библиотеки UDF)	ib_udf.dll, fbudf.dll	C:Program FilesFirebirdUDF
Библиотека утилиты памяти (используется в ib_udf.dll)	ib_util.dll	C:Program FilesFirebirdbin
Скрипты DDL для библиотек внешних функций	ib_udf.sql, fbudf.sql	C:Program FilesFirebirdUDF
Библиотека поддержки интернациональных языков	gdsintl.dll	C:Program FilesFirebirdintl
Документация	Файлы README по различным темам	C:Program FilesFirebird
Пример базы данных	employee.gdb	C:Program FilesFirebirdsample
Заголовочные файлы С	ibase.h, iberror.h и др.	C:Program FilesFirebirdinclude

Пора дальше

Firebird состоит из программы сервера и клиентских приложений; между сервером и каждым клиентом располагается сетевой протокол. Если вы использовали соответствующий инсталлятор для вашей платформы и использовали значения по умолчанию, вероятно, вам больше ничего не потребуется делать, и можно сразу приступать к началу работы. Вы можете пропустить две следующие главы и перейти к «основам», описанным в главе 4. Если вас интересуют сетевые протоколы или вам кажется, что у вас есть проблемы, связанные с сетевыми протоколами, прочтите следующую главу, и, возможно, просмотрите некоторые советы по конфигурированию в главе 3.

ГЛАВА 2. Установка сети.

Поскольку реляционная система управления базами данных (РСУБД) специально создана для платформы клиент-сервер, Firebird позволяет удаленным и локальным клиентам одновременно соединяться с сервером, используя различные сетевые протоколы.

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

Сетевые протоколы

Firebird поддерживает протокол TCP/IP для всех комбинаций клиентских и серверных платформ.

Именованные каналы

Firebird поддерживает протокол Мiсrоsоft WNet Named Pipes для серверов Windows NT/2000, XP и клиентов Windows. Имя канала по умолчанию interbas. Windows 9х и ME не Moryт быть серверами WNet.

! ! !

ПРИМЕЧАНИЕ. Протокол Windows Named Pipes (именованные каналы) часто называют NetBEUI. Строго говоря, NetBEUI является транспортной частью, используемой в WNet.

. ! .

Локальный доступ

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

Firebird поддерживает протокол Microsoft WNet Named Pipes для серверов Windows NT/2000, XP и клиентов Windows. Имя канала по умолчанию interbas. Windows 9х и ME не могут быть серверами WNet.

Клиент-сервер

Средства локального доступа.

* Локальная заглушка TCP/IP. Для многоуровневых серверных приложений и других клиентов доступ к локальному серверу на любой поддерживаемой платформе осуществляется через протокол TCP/IP: даже при отсутствии сетевой карты соединение может быть выполнено через специальный сервер localhost с IP-адресом 127.0.0.1.

! ! !

ВНИМАНИЕ! Соединение с localhost невозможно для приложений встраиваемого сервера.

. ! .

* Режим локального соединения Windows. Для клиентов Windows, использующих Суперсервер Firebird на той же самой физической машине, Firebird поддерживает режим локального соединения, используя межпроцессную передачу данных для моделирования сетевого соединения без интерфейса физической сети и сетевого протокола. Это полезно при доступе к базе данных в процессе разработки, для приложений встраиваемого сервера и для консольных инструментов клиента, но в этом варианте не поддерживается механизм событий Firebird и параллельная работа клиентской части из разных потоков приложения.

Средства локального соединения клиент-сервер являются ограниченными и не должны использоваться при поставках программ. Распространяйте автономные приложения клиент-сервер, Web-приложения и другие уровни серверов с использованием для соединения локально закольцованного протокола TCP/IP.

* Прямое локальное соединение в POSIX. Может ли локальный клиент соединяться с базой данных в Linux и в некоторых других системах POSIX, зависит, в первую очередь, от варианта сервера, который вы инсталлировали (Классический сервер или Суперсервер), и, во вторую очередь, от типа клиентского соединения.

Суперсервер совсем не принимает локальных соединений через обычный клиентский API. Путь для соединения всегда должен включать имя хоста TCP/IP. Тем не менее он принимает локальные соединения от «встроенных приложений» (приложений, написанных с использованием встроенного SQL — Embedded SQL, ESQL). Инструменты командной строки, gsec, gfix, gbak и gstat, которые являются встроенными приложениями, могут выполнять локальные соединения с Суперсервером.

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

Встраиваемый сервер

Начиная с Firebird 1.5, пакеты Firebird для Windows включают полную функциональность встраиваемого сервера (клиент и сервер соединяются как динамическая библиотека). Это идентично обычной модели клиент-сервер, за исключением того, что здесь не поддерживается сетевой протокол: соединение осуществляется в стиле «локальной Windows» для эмуляции сетевого соединения.

! ! !

ВНИМАНИЕ! Встраиваемый сервер не поддерживает пароль безопасности доступа Firebird.

. ! .

Смешанные платформы

Архитектура Firebird позволяет клиентам, запущенным в одной операционной системе, получить доступ к серверу Firebird, выполняющемуся на платформе и в операционной системе, отличных от клиентских. Часто используемый вариант- одновременный запуск нескольких недорогих персональных компьютеров с Windows 98 в качестве клиентских рабочих станций, имеющих доступ к главному серверу, выполняющемуся под Windows NT/2000/XP, Linux или под некоторой версией UNIX.

База данных, которая была создана для использования на одной модели сервера, может работать на любом из них. Например, когда приложение встраиваемого сервера неактивно, его база данных может находиться под управлением другого приложения встраиваемого сервера или полного сервера Firebird, обслуживающего удаленных клиентов. Та же база данных может быть без изменений перенесена с одной платформы на другую^[4].

К тому же платформы Windows и Linux, реализации сервера Firebird (Классический, Суперсервер или оба) работают также в Mac OS X (Darwin), FreeBSD, Sun Solaris (Intel и SPARC), HP-UX, потенциально в AIX и могут быть созданы для множества дополнительных платформ UNIX.

Firebird в настоящее время не поддерживает ни платформу Novell NetWare, ни другие виды сетей, которые используют устаревший протокол IPX/SPX. С прекращением со стороны Novell поддержки этого протокола сайты часто используют серверы Firebird в системе Linux с сетевыми клиентами, подключенными к этой подсистеме через TCP/IP.

Сетевой адрес для сервера

Для связи через TCP/IP вы должны соединяться с хостом, который имеет известный адрес IP. Определение того, какой это адрес IP (или каким должен быть, если он отсутствует), зависит от вида сетевого оборудования вашей хост-машины.

* Если вы находитесь в управляемой сети, получите IP-адрес сервера у вашего системного администратора.

* Если у вас простая сеть из двух машин, соединенных кабелем с перекрестными проводниками, или малая переключаемая сеть, вы можете установить для вашего сервера любой подходящий уникальный адрес IP, какой вам нравится, за исключением 127.0.0.1 (который резервируется для локальной заглушки TCP).

* Если вам известны «родные» адреса IP ваших сетевых карт, и они различны, вы можете просто использовать их.

* Если вы собираетесь пробовать инсталляцию на одной машине и для клиента, и для сервера, вы должны использовать адрес локально закольцованного сервера — localhost или его IP-адрес 127.0.0.1.

! ! !

ВНИМАНИЕ! В Windows один пользователь может локально соединиться с сервером без использования локального TCP/IP как внешний или как встроенный клиент. Серверный адрес не требуется для такого соединения и не может быть использован для проверки того, правильно ли работает TCP/IP при вашей инсталляции.

. ! .

Файл HOSTS

Если в вашей TCP/IP-сети не запущен сервис имен доменов, то необходимо проинформировать индивидуально каждый узел о распределении адресов IP в именах хоста вашей сети. Для этого измените файл HOSTS для каждого узла (сервер и клиент).

При установке узлов Firebird вашей TCP/IP-сети рекомендуется конфигурировать файлы имен хоста на клиентах и использовать имена, а не напрямую адреса IP при подключении к серверу. Хотя большинство последних операционных систем могут использовать IP-адрес хоста в строке соединения вашего клиента вместо имени хоста, соединение через имя хоста гарантирует, что адрес сервера остается статичным, несмотря на динамическое изменение адресов в сети.

! ! !

ВНИМАНИЕ! Для рабочих станций, работающих под Windows 95 и ранней версии Windows 98, где клиентские станции работают в старой 32-битовой версии Windows, сетевая поддержка вовсе не распознает IP-адрес в строке соединения, потому что эти версии инсталлировались с Winsock 1. В любом случае инсталляция Winsock 2 более соответствует требованиям текущих версий Firebird. Свободно распространяемые пакеты обновлений могут быть загружены с сайтов поддержки пользователей Microsoft.

. ! .

Местонахождение файла HOSTS

Перечислим, где можно найти файл HOSTS.

* В Linux и многих версиях UNIX файл HOSTS обычно расположен в /etc/. Помните, что имена файлов являются чувствительными к регистру на платформах семейства UNIX.

* В Windows NT/2000 файл HOSTS располагается в C:WMNTsystem32driversetc.

* В Windows 95/98/ME/XP/Server2003 файл HOSTS располагается в C:Windows.

! ! !

СОВЕТ. Если файл HOSTS отсутствует, вы найдете файл с именем Hosts.SAM в том же месте. Скопируйте этот файл и переименуйте в HOSTS.

. ! .

Примеры записей файла:

10.12.13.2 db_server # Firebird-сервер (в LAN)

65.215.221.149 apress.com # (сервер в WAN)

127.0.0.1 localhost # локальная заглушка (в Windows)

127.0.0.1 localhost.localdomain # локальная заглушка(в Linux)

Откройте и отредактируйте файл HOSTS в текстовом редакторе. Создание записей простое. Тем не менее обеспечьте, чтобы:

* IP-адрес, если это не 127.0.0.1 (localhost), был действительным, сконфигурированным для хоста в вашей сети;

* имя сервера было любым уникальным именем в вашей сети;

! ! !

СОВЕТ. Серверная машина под Windows, которая была установлена в Windows Networking (Named Pipes) с именем хоста //Server_name, будет распространять это имя как имя хоста TCP/IP.

. ! .

* комментарии после символа # необязательны, но

рекомендуются;

* формат записей одинаков, независимо от того, под какой системой запущен хост — Windows или Linux/UNIX.

! ! !

ВНИМАНИЕ! После того как вы отредактировали файл HOSTS, проверьте, что ваш редактор сохранил HOSTS без расширения имени файла. Если необходимо, удалите любое расширение, переименовав файл.

. ! .

Имя сервера и путь к нему

При создании или перемещении базы данных убедитесь, что она располагается на жестком диске, который физически соединен с вашей серверной машиной. Файлы базы данных, расположенные на разделенных, назначенных дисках или (для UNIX) смонтированных как файловая система SMB (Samba), невидимы для сервера.

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

Об алиасах базы данных см. главу 4.

Синтаксис строки соединения

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

TCP/IP

Строка соединения TCP/IP содержит два элемента: имя сервера и абсолютный путь диска/файловой системы, такой, как его видит сервер. Формат следующий:

* для соединения с сервером Linux:

имя-сервера: /путь-файловой-системы/файл-базы-данных

Вот пример для Linux или другой операционной системы семейства UNIX для сервера с именем hotchicken:

hotchicken:/opt/firebirdl5/examples/LeisureStore.fdb

! ! !

ВНИМАНИЕ! Помните, что для этих платформ все имена файлов являются чувствительными к регистру.

. ! .

* для соединения с сервером Windows:

имя-сервера:Диск: путь-файловой-системыфайл-базы-данных

Пример:

hotchicken:С:Program FilesFirebirdl5examplesLeisureStore.fdb

Прямая наклонная черта также допустима в Windows:

hotchicken:С:/Program Files/Firebirdl5/examples/LeisureStore.fdb

Локальное соединение в Windows

Соединение встроенного клиента или локального внешнего клиента в локальном режиме Windows:

C:Program FilesFirebirdl5examplesLeisureStore.fdb

Сеть Windows (Named Pipes/WNet)

Соединение удаленного клиента сервера Windows с использованием протокола Named Pipes:

\имя-сервераДиск:путьфайл-базы-данных

где \имя-сервера — правильный идентификатор имени узла серверной машины в сети Windows, не может быть разделяемым или назначенным диском. Например,

\hotchickenc:databasesLeisureStore.fdb

Несовместимые строки соединения для подключений Windows

Суперсервер для Windows устанавливает исключающую блокировку на файл базы данных, когда активируется первое клиентское подключение, чтобы защитить базы данных от старой ошибки.

Ошибка в пути соединения

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

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

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

! ! !

СОВЕТ. Настоятельно рекомендуется использовать алиасы базы данных (см. разд. «Алиасы базы данных» е главе 4) для всех соединений. Убедитесь также, что файл aliases.conf содержит один и только один алиас для каждой базы данных.

. ! .

Конфигурирование сервиса порта TCP/IP

По умолчанию Firebird прослушивает порт 3050 при запросе соединения от клиентов TCP/IP. Зарегистрированное имя сервиса этого порта gds_db. Хорошая новость — вы можете использовать эти установки по умолчанию и ничего не делать с конфигурацией сервиса порта ни для сервера, ни для клиента.

Вы можете использовать другой порт, другое имя сервиса порта или и то, и другое. Вам может понадобиться это сделать, если порт 3050 требуется для другого сервиса, например, если параллельно используемый gds_db сконфигурирован для другой версии Firebird или для сервера InterBase. Есть несколько способов перекрыть значения по умолчанию. Сервер и клиенты оба должны быть сконфигурированы для изменения имени сервиса или номера порта (или и того, и другого) по меньшей мере одним из следующих способов:

* в строке соединения клиента;

* в команде запуска исполняемой программы сервера;

* активацией параметров RemoteServicePort или RemoteServiceName В firebird.config (версия 1.5 и выше);

* в демоне конфигурации (для Классического сервера в POSIX);

* в записи файла services.

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

Как сервер устанавливает прослушиваемый порт

Исполняемая программа сервера имеет необязательный переключатель в командной строке (-р), который можно использовать для указания номера порта или имени сервиса порта, который будет прослушиваться сервером. Если присутствует этот переключатель, то номер порта 3050 или имя сервиса порта (gds_db) будут заменены на значение аргумента, указанного в переключателе -р.

Затем- или вначале, если не установлен переключатель -р,- сервер версии 1.5 проверяет наличие параметров RemoteServicePort и RemoteServiceName В firebird.config.

* Если оба параметра закомментированы с использованием #, то принимаются значения по умолчанию, и никакие дальнейшие изменения не выполняются. Любой аргумент -р игнорируется, и «отсутствующие» аргументы сохраняют значение по умолчанию.

* Если RemoteServiceName (но не RemoteServicePort) не закомментирован, то имя сервиса порта заменяется, только если это имя не было уже перекрыто переключателем -р.

* Если RemoteServicePort и RemoteServiceName не закомментированы, ТО RemoteServiceName получает приоритет, если он не был перекрыт аргументом -р. Если же имя сервиса порта уже было изменено, то значение RemoteServiceName будет проигнорировано, и новое значение RemoteServicePort заменит предыдущее значение 3050.

* В этой точке, если замена номера порта или имени сервиса была выполнена, то оба сервера версий 1.0 и 1.5 выполняют проверку файла services на наличие записи с корректной комбинацией имени сервиса и номера порта. Если соответствие найдено, то все в порядке. Если нет, и имя сервиса порта не gds db, то сервер выдаст исключение и отменит запуск. Если имя сервиса порта gds db и ему не может быть назначен никакой другой порт, он будет использовать порт 3050 автоматически.

Если значение по умолчанию для номера порта или имени сервиса было изменено, то вам может понадобиться создать запись в файле services. Для понимания того, нужно ли это делать, выполните шаги, описанные далее в этой главе в разд. «Конфигурирование файла services».

Использование переключателя -p

Запуск сервера с необязательным переключателем -р дает вам возможность перекрывать значение по умолчанию для номера порта (3050) или имя сервиса порта (gds db), которые используются сервером для прослушивания запросов на соединение. Переключатель может перекрывать одно значение, но не оба. В Firebird 1.5 и следующих вы можете использовать переключатель -р в комбинации с конфигурацией в файле firebird.conf для получения возможности перекрывать и номер порта, и имя сервиса порта.

Синтаксис для TCP/IP

Шаблон синтаксиса для команд:

Команда-сервера <другие переключатели< -р номер-порта j имя-сервиса

Например, для запуска Суперсервера как приложения и замены имени сервиса с gds_db на fb_db введите:

fbserver -а -р fb_db

Для замены порта 3050 на 3051 введите:

fbserver -а -р 3051

Синтаксис для Wnet

Для сети Wnet замените аргумент переключателя -р на обратная черта-обратная черта-точка-@:

fbserver -а -р \.@fb_db

ИЛИ

fbserver -а -р \.@3051

Классический сервер в POSIX: демон inetd или xinetd

В Классическом сервере Firebird для Linux или UNIX демон inetd или xinetd сконфигурирован на прослушивание порта по умолчанию и имя сервиса по умолчанию. Инсталляционный скрипт запишет соответствующую запись в файл конфигурации /etc/inetd.conf или /etc/xinetd.conf.

Проблемы с подключением к Классическому серверу часто происходят по причине отсутствия или неправильной записи сервиса порта в этом файле. Вы можете проверить текущую запись, открыв файл в текстовом редакторе (например, vim) и скорректировав ее при необходимости. Следующий пример показывает, что вы должны увидеть в файле /etc/inetd.conf или /etc/xinetd.conf после инсталляции Классического сервера Firebird в Linux:

# default: on

# description: FirebirdSQL server

service gds_db

(

flags = REUSE KEEPALIVE

socket_type = stream

wait = no

user = root

# user = @FBRunUser@

log_on_success += USER1D

log_on_failure += USER1d

server = /opt/firebird/bin/fb_inet_server

disable = no

)

Если вы изменили сервис порта на значение, отличное от значения по умолчанию, вы должны соответственно изменить /etc/inetd.conf или /etc/xinetd.conf. Заново стартуйте xinetd (или inetd) с аргументом kill -HUP, чтобы убедиться, что демон будет использовать новую конфигурацию.

! ! !

ВНИМАНИЕ! Запросы на соединения будут неуспешными, если xinetd (или inetd) и fbserver (или ibserver) оба пытаются прослушивать один и тот же порт. Если ваша хост-машина имеет подобную дублирующую конфигурацию, то необходимо сделать такие установки, при которых каждая версия сервера имела бы свой собственный порт.

. ! .

Использование параметров файла конфигурации

В Firebird 1.5 и выше вы можете конфигурировать или RemoteServiceName, или RemoteServicePort в файле firebird.config для изменения номера порта по умолчанию (3050), или имени сервиса порта по умолчанию (gds_db), которые использует сервер для прослушивания запросов на соединение.

Сервер будет использовать один параметр Remoteservice*, но не оба. Если вы сконфигурировали оба, то он будет игнорировать RemoteServicePort во всех ситуациях, за исключением того случая, когда команда запуска сервера была вызвана с переключателем -р, перекрывающим имя сервиса порта. Следовательно, вы можете использовать в комбинации переключатель -р и параметр Remoteservice* для изменения номера порта и имени сервиса.

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

! ! !

ВНИМАНИЕ! Если вы не закомментировали ни RemoteServiceName, ни RemoteServicePort, но оставили значения по умолчанию нетронутыми, они будут трактоваться как измененные. Необходимо создать запись в файле services для установок значений по умолчанию сервиса порта.

. ! .

Установка клиента для поиска порта сервиса

Если вы установили ваш сервер с инсталляционными значениями по умолчанию (сервис gds db прослушивает порт 3050), то конфигурирование не требуется. Если сервер прослушивает другой порт или используется другое имя сервиса порта, то приложение клиента и/или хост-машины требуют некоторых изменений конфигурации, чтобы помочь клиентской библиотеке Firebird найти прослушиваемый порт.

Строка соединения, используемая клиентом, может включать информацию для опроса прослушиваемого порта сервера разными путями. Клиенты Firebird 1.5 могут использовать локальную копию firebird.conf. Изменения также могут понадобиться и для файла services.

Использование строки соединения

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

Синтаксис соединения TCP/IP

Для соединения с сервером базы данных, названным hotchicken, связанным с портом 3050 и сервисом fb_db, строка соединения в POSIX должна быть следующей:

hotchicken/fb_db:/data/leisurestore.fdb

Если же сервер имеет имя gds db, а номер порта 3051, то строка соединения должна быть следующей:

hotchicken/3051:/data/leisurestore.fdb

В Windows строка соединения должна быть:

hotchicken/3051:D:dataleisurestore.fdb hotchicken/fb_db:D:dataleisurestore.fdb

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

Синтаксис соединений Wnet

В сети Wnet используйте стиль нотаций UNC:

\hotchicken@3051d:leisurestore.fdb

или

\hotchicken@fb_dbd:leisurestore.fdb

Если номер порта или имя сервиса были изменены, то вам нужно создать запись в файле services.

Использование синтаксиса порта для алиасов базы данных

Для соединения через порт, не являющегося портом по умолчанию, с помощью алиаса базы данных добавьте номер порта или имя сервиса к имени сервера, а не к алиасу. Предположим, что алиас базы данных был сохранен в aliases.conf в виде:

hotstuff = /data/leisurestore.fdb

Строка соединения вашего приложения с сервером hotchicken будет следующей:

hotchicken/fb_db:hotstuff

или

hotchicken/3051:hotstuff

Использование копии firebird.conf

В Firebird 1.5 и выше вы можете скопировать на клиентскую сторону в корневой каталог Firebird файл firebird.conf и сконфигурировать RemoteServiceName или RemoteServicePort для помощи клиенту в поиске серверного порта.

Вы можете конфигурировать один из этих двух параметров; изменение значения другого параметра можно выполнить через строку соединения (см. ранее). Вы можете перекрыть значение только RemoteServiceName или RemoteServicePort без использования строки соединения.

Если вам не нужно передавать имя сервиса порта или номер порта в строке соединения, а сервер не использует значения по умолчанию для обоих параметров, вы можете конфигурировать оба RemoteServiceName и RemoteServicePort. Вы можете использовать эту технику, если вашему клиентскому приложению нужно сохранить возможность соединяться с серверами InterBase или Firebird 1.0.

Размещение данных Firebird на клиентах

Если вы используете на клиентских машинах файл firebird.conf, нужно, чтобы клиентская библиотека знала, где его найти. Вам необходимо создать корневой каталог Firebird и проинформировать систему о его местонахождении. Используйте для этого переменную среды FIREBIRD таким же образом, как и для серверов (см. главу 3). Клиенты Windows могут также использовать запись в реестре. При правильной установке клиента вы можете также сделать доступной локальную версию файла сообщений. Более подробную информацию см. в разд. «Инсталляция клиентов» в главе 7.

Конфигурирование файла services

Вам не нужно изменять запись сервиса порта для сервера или клиентов Firebird, если сервер использует значения по умолчанию, заданные при инсталляции — gds db для порта 3050. Если gds db — имя сервиса порта, который не может использовать любой другой порт, то он будет применять порт 3050 автоматически.

Если вы изменили номер порта или имя сервиса, вы должны сделать явные изменения для сервера и клиентов, чтобы отобразить эти изменения. В Linux и Windows данная информация хранится в файле services.

Местонахождение файла services

Местонахождение файла services на разных платформах:

* в Windows NT/2000/XP этот файл находится в C:winntsystem32drivers etcservices;

* в Windows 95/98/ME файл находится в C:Windowsservices;

* в Linux/UNIX файл находится в /etc/services.

Записи файла services выглядят следующим образом:

gds_db 3050/t.cp # Firebird Server 1.5

Откройте файл в текстовом редакторе и добавьте новую строку или измените существующую запись gds db.

* Для сервера или клиента Firebird 1.0.x измените имя сервиса или номер порта для согласования с параметрами запуска сервера.

* Для сервера Firebird 1.5 или выше отредактируйте или добавьте нужную строку. Если у вас инсталлирован сервер Firebird 1.0 или InterBase на том же хосте, сохраните нужные для них записи и добавьте новую запись для согласования с параметрами запуска сервера.

! ! !

ПРИМЕЧАНИЕ. Если данная строка является последней в файле services, то рекомендуется в конце файла добавить пустую строку.

. ! .

Проверка соединения с помощью ping

Вы сделали все нужные изменения. Последняя проверка нужна, чтобы убедиться, что ваша клиентская машина может связываться с сервером. Вы можете быстро проверить, что ваш клиент TCP/IP связывается с сервером, используя в окне командной строки команду ping:

ping имя-сервера// подставьте имя, которое вы записали в файле HOSTS

Если соединение прошло хорошо, и все правильно сконфигурировано, вы увидите приблизительно следующее:

Pinging hotchicken [10.10.0.2] with 32 bytes of data

reply from 10.10.0.2: bytes=32 time<10ms TTL=128

reply from 10.10.0,2: bytes=32 time<10ms TTL=128

Нажмите комбинацию клавиш <Ctrl>+<C> для прекращения сообщений ping.

Если ping выдает ошибку

Если вы получили нечто вроде

Bad IP address hotchicken (Неверный IP-адрес hotchicken)

то имя хоста в записи файла для имя-сервера (в этом примере hotchicken) может быть отсутствует или неверно написано. К примеру, все идентификаторы в Linux/UNIX являются чувствительными к регистру. Другая причина может заключаться в том, что имя хоста вашего сервера просто не было сконфигурировано.

Если вы увидите:

Request timed out

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

* нет ошибок в имени хоста в записи файла;

* сетевой кабель подключен, провод и контакты не повреждены и не ржавые;

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

• Ограничения подсети: TCP/IP может быть сконфигурирован для ограничения трафика между подсетями. Если ваша клиентская машина является частью сложной сети или подсети, уточните у сетевого администратора, имеет ли она неограниченный доступ к серверу.

! ! !

ВНИМАНИЕ! WNet не позволяет направлять сетевой трафик между подсетями.

. ! .

• Система сетевой защиты (firewall): ваша проверка соединения может дать ошибку, если сервер базы данных находится под программной или аппаратной системой сетевой защиты, которая блокирует порт 3050 или сконфигурированный вами порт.

Проблемы с событиями

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

В Firebird 1.0.x ваш сетевой администратор должен установить некий способ, чтобы гарантировать наличие доступного порта, который всегда свободен, открыт и является статическим. Проблема может быть решена тем или иным образом в большинстве сетей.

Firebird 1.5 упрощает дело. Он делает возможным явно задавать IP-адрес в сети для трафика событий. Используйте параметр RemoteAuxPort в файле firebird.conf с целью статической установки IP-адреса для интерфейса (карта, маршрутизатор, шлюз и т.д.), который будет доступен для направления событий.

Более подробно о событиях Firebird см. главу 32.

Другие сетевые проблемы

Если дела идут плохо, вы можете найти немало советов в приложении 2.

Пора дальше

Куда дальше? Если у вас все в порядке с установками сети, и вам не терпится идти дальше, переходите прямо к главе 4 для изучения «основ», которые помогут вам соединиться с базой данных. Если же вы инсталлировали Firebird в мультипроцессорной системе, или вы подозреваете, что некоторые элементы конфигурации вашей машины могут вызвать проблемы, читайте дальше. Несмотря на то, что редко бывает нужным изменять конфигурацию Firebird для основных операций, в главе 3 описывается несколько опций конфигурации, которые могут помочь вам избавиться от головной боли.

ГЛАВА 3. Конфигурирование Firebird.

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

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

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

Конфигурация на уровне базы данных

Эта глава посвящена конфигурации на уровне сервера. Один сервер Firebird может работать с несколькими базами данных одновременно. Каждая база данных может быть сконфигурирована таким образом, чтобы соответствовать предъявляемым к ней требованиям. Конфигурирование на уровне базы данных см. в главах 15 и 39.

Переменные окружения

Переменные окружения — глобальные установки системы, которые используются при первоначальной загрузке операционной системы. В Windows, Linux и в большинстве систем UNIX сервер Firebird распознает и использует некоторые переменные окружения, если они установлены. Процессы fbserver (архитектура Суперсервера) и fb inet server (архитектура Классического сервера) не распознают установок, которые ссылаются на сетевые ресурсы (диски и файловые системы), не управляемые физически серверной машиной.

Где устанавливаются переменные окружения

Windows

Тип переменных окружения и способ их установки меняется от одной версии Windows к другой. В табл. 3.1 показаны типы (если применимы) и способы установки значений переменным окружения.

Таблица 3.1. Установки переменных окружения для Windows

Версия Windows	Тип переменной	Описание	Наличие
Windows 95/98	He применяется	Используйте Блокнот и установите переменные окружения в autoexec.bat или config.sys. Формат установки: SET <имя переменному = значение переменному. Пример: SET FIREBIRD=C:PROGRAMFIREBIRD. Для просмотра всех текущих установок переменных окружения наберите SET в командной строке	Нет
Windows NT/2000/XP	Переменные пользователя. Делает переменные доступными для приложений, запускаемых конкретным пользователем, если этот пользователь подключен	Используется для ограничения видимости переменных определенным пользователям. Диалоговое окно Свойства системы (System Properties), доступное через апплет Система (System applet) на Панели управления или через контекстное меню, появляющееся при щелчке правой кнопкой мыши на объекте Мой Компьютер и выборе элемента Свойства	Да
Windows NT	-//-	Выберите Расширенное окружение \| Новое (Advanced Environment \| New)
Windows 2000/XP	-//-	Выберите Расширенное окружение \| Переменные окружения \| Новое (Advanced Environment \| Variables \| New)
Windows NT/2000/XP	Системные переменные. Доступны для всей системы (все сервисы, все пользователи). Команды SET записаны в командной строке. Переменные доступны только процессам, запущенным из командной строки	Используйте, если Firebird запущен как сервис. Выберите Расширенное окружение \| Переменные окружения \| Новое (Advanced Environment \| Variables \| New) или Редактировать (Edit), если доступно	Да
-//-	-//-	Полезно для установки переменной окружения для временного использования (например, ISC_USERH ISC_PASSWORD для упрощения доступа из утилит командной строки при выполнении задач администратора). Используйте SET <имя_переменной> = <значение переменной> для установки значения переменной; используйте SET <имя_переменной> =, чтобы установить пустое значение	Нет

POSIX

В Linux и UNIX самый простой путь установления переменных окружения — добавить их определения в общесистемный профиль значений по умолчанию.

Пользователь root также может:

* выдать команды setenv() из командной строки wu командного скрипта;

* для временного использования установить и экспортировать переменную из командной строки, например, export ISC_USER=SYSDBA.

ISC_USER и ISC_PASSWORD

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

Если вы не указываете имя пользователя и пароль при локальном соединении с базой данных, или когда вы запускаете утилиты командной строки, такие как gbak, gstat или gfix, Firebird проверяет, установлены ли переменные окружения ISC_USER и ISC PASSWORD. Если установлены, Firebird позволяет вам соединиться без указания пароля. Никогда не оставляйте эти переменные установленными на сервере, который содержит важные базы данных, если помещение, где располагается сервер, не является физически хорошо защищенным!

Переменная FIREBIRD (или INTERBASE)

Если установлена переменная окружения FIREBIRD (INTERBASE для версии 1.0.x), то она используется и при инсталляции, и в процессе работы на всех платформах для указания корневого каталога сервера Firebird. Если она присутствует, то перекрываются все другие установки — значения по умолчанию инсталляционного пакета, установки в реестре Windows, конфигурация в firebird.conf, значения глобальных путей операционной системы и т.д.

В процессе инсталляции она указывает на каталог, в котором должен быть установлен Firebird. Значение переменной должно задавать полный путь, который существует в физической файловой системе на хост-машине. При старте сервер читает значения в файле конфигурации firebird.conf (или ib_config/isc_config в версии 1.0.x), который должен находиться в каталоге, назначенном переменной FIREBIRD (ИЛИ INTERBASE). Этот каталог должен быть родительским для каталога bin, где размещаются двоичные файлы Firebird. Здесь также по умолчанию находятся файлы сообщений и замков: firebird.msg (interbase.msg) и hostname.lck.

! ! !

ПРИМЕЧАНИЕ. Вы можете указать другое размещение файлов firebird.msg (interbase.msg) и firebird.lck (interbase.lck), установив переменные окружения FIREBIRD_MSG (INTERBASE_MSG) и FIREBIRD_LOCK (INTERBASE_LOCK). см. следующие разделы.

. ! .

Если переменная FIREBIRD не установлена, будут использованы значения по умолчанию:

* /opt/firebird — для платформ Linux/UNIX;

* C:Program FilesXFirebird (версия 1,0.x) или C:Program FilesFirebirdFirebird_1_5 (версия 1.5) — для платформ Windows.

В табл. 1.2-1.5 в главе 1 указаны точные пути. Если Firebird установлен в каталоге, отличном от каталога по умолчанию, и задана переменная FIREBIRD, то клиентская библиотека будет читать значение переменной для определения пути инсталляции.

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

HKEY_LOCAL_MACHINESOFTWAREFirebird ProjectFirebird ServerInstances

Более подробное обсуждение способов поиска сервером размещения этих файлов см. далее в этой главе в разд. «Корневой каталог Firebird». Информацию об установках только клиента см. в разд. «Установка клиентов» главы 7.

FIREBIRD_TMP

По умолчанию Firebird будет использовать глобальное пространство временных файлов, обычно задаваемое как системное значение по умолчанию переменной окружения TMP (обсуждается далее). Переменная окружения FIREBIRD_TMP (В версии 1.0.x — INTERBASE TMP) задает пользовательское размещение для файлов сортировки Firebird. Значение должно указывать полный путь, который существует в физической файловой системе хост-машины.

Доступны также другие способы определения размещения этих файлов. Конфигурирование параметра TempDirectories (TMP_DIRECTORY в версии 1.0.x) описано в разд. «Файл конфигурации Firebird» и разд. «Параметры для конфигурирования пространства временной сортировки» главы 36.

_LOCK и _MSG

FIREBIRD_LOCK (INTERBASE_LOCK В версии 1,0.x) устанавливает расположение файла блокировок. FIREBIRD_MSG (INTERBASE_MSG в версии 1.0.x) устанавливает расположение файла сообщений Firebird.

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

TMP

Пространство сортировки на серверной машине

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

Глобальная переменная окружения TMP (или TEMP В некоторых системах) указывает каталог на сервере, где приложения должны сохранять временные файлы. Firebird попытается сохранить временные файлы сортировки именно здесь, если не определена переменная окружения FIREBIRD_TMP (см. разд. «FIREBIRD TMP») и в файле конфигурации Firebird не указано пространство сортировки (см. переменные TempDirectories и TMP_DIRECTORY В главе 36).

Файлы скриптов isql на клиенте

Интерактивная утилита командной строки isql предоставляет возможность записывать последовательность интерактивных команд SQL в файл скрипта при использовании переключателя OUTPUT. На клиентской машине переменная TMP задает расположение этих файлов скриптов, если не было указано другого абсолютного пути. Если переменная TMP не установлена, то клиент Firebird использует любой другой временный каталог, который будет найден в локальной системе, обычно tmp в файловой системе клиента Linux/UNIX или C:Temp в клиенте Windows.

Файл конфигурации Firebird

Firebird не требует постоянной сложной реконфигурации, которая необходима другими тяжеловесными РСУБД. Тем не менее целый ряд вариантов конфигурирования доступен для настройки сервера Firebird и хост-системы, на которой он выполняется, под ваши специальные требования.

Файл конфигурации Firebird называется firebird.conf для всех версий Firebird 1.5 и выше. В предыдущих версиях его имя зависело от операционной системы:

* isc config — в Linux/UNIX;

* ibconfig — в Windows.

В версии 1.5 было добавлено несколько новых параметров.

Когда стартует сервер Firebird, он читает файл конфигурации и настраивает свои флаги времени выполнения (runtime flags), если файл конфигурации содержит значения, отличные от установленных по умолчанию. Данные из файла больше не будут считываться, пока не произойдет новый запуск сервера. Параметры конфигурации по умолчанию и их значения содержатся в файле конфигурации и закомментированы символом #. Нет необходимости убирать комментарий, чтобы сделать значения по умолчанию видимыми процедуре запуска сервера.

Изменение параметров конфигурации

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

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

Записи параметров в файле firebird.conf представлены в форме:

имя_параметра = значение

где имя_параметра — строка, содержащая имя параметра (без пробелов), а значение — это число, логическая константа (1=Истина, 0=Ложь) или строка, которые задают значение параметра.

Для задания параметру значения, отличающегося от значения по умолчанию, удалите символ примечания (#) и отредактируйте значение.

Имена параметров и синтаксис в файле ibconfig/isc_config для Firebird 1,0.x отличаются от того, что может содержаться в firebird.conf. Формат, размер и количество параметров являются более ограниченными.

Формат в ibconfig/isc conflg:

имя_параметра значение

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

Помните, что в Linux параметры чувствительны к регистру.

! ! !

ПРИМЕЧАНИЕ. Вы можете редактировать файл конфигурации и когда сервер запущен. Для активации изменений нужно остановить и заново запустить сервер.

. ! .

Корневой каталог Firebird

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

1. На любой платформе сервер в первую очередь смотрит глобальную переменную окружения FIREBIRD. Если он находит эту переменную, ее значение будет использовано без всяких условий.

2. Если переменная окружения FIREBIRD отсутствует, то для платформ Windows сервер отыскивает ключ в реестре

HKEY_LOCAL_MACHINESOFTWAREFirebird ProjectFirebird ServerInstances

и смотрит поле oefauitinstance. Если он находит в данном поле правильный путь к каталогу, то использует это значение. Другие платформы не имеют подобного указателя.

3. Если корневой каталог все еще не найден, то предполагается, что временный корневой каталог располагается на один уровень выше каталога запущенного процесса (,. для Windows и ../ или ссылка на /proc/self/exe для POSIX, если доступно).

4. Теперь процедура запуска ищет в этом каталоге файл firebird.config. Если файл firebird.config найден, то процедура отыскивает параметр RootDirectory. Если параметр присутствует, его значение становится окончательно корневым каталогом, иначе промежуточное значение из n.3 становится окончательным значением.

! ! !

ВНИМАНИЕ! Если файл firebird.config не был найден на уровне, предшествующем запускаемому процессу, это может означать, что корневой каталог не был определен по причине нестандартной инсталляции. Сервер должен найти корневой каталог файлов. Если вам встретилась ошибка безопасности или ошибка файловой системы в процессе соединения или во время выполнения, вы должны пересмотреть ваши пути инсталляции, чтобы убедиться, что все действия, описанные в данном разделе, правильно определили корневой каталог файлов и подкаталоги.

. ! .

Параметры, связанные с доступом к файлам

Firebird имеет несколько параметров для защиты его файлов и баз данных от разрушающего или неавторизованного доступа. Если вы перемещаете приложение работы с базой данных или используете инструмент администратора для Firebird 1.5, вам следует обратиться к разд. «Файл конфигурации Firebird» в главе 36 для получения детальной информации об указанных далее параметрах.

* RootDirectory — может быть использован для изменения абсолютного пути к корневому каталогу в локальной файловой системе. Он должен оставаться закомментированным, если только вы не захотите изменить процедуру запуска, перекрыв путь к корневому каталогу инсталляции сервера Firebird (см. n. 3 в предыдущем разделе).

* DatabaseAccess — в Firebird 1.0.x сервер может соединяться с любой базой данных в его локальной файловой системе и всегда доступен приложениям, передающим абсолютный путь к файлу в файловой системе. Этот параметр был введен в версии 1.5, чтобы обеспечить более четкое управление безопасностью при доступе к файлам базы данных, а также для поддержки средства алиасов баз данных.

Инсталляция по умолчанию устанавливает значение параметра в Full, чтобы имитировать поведение Firebird версии 1,0.x. Альтернативные режимы могут ограничить доступ сервера только к базам данных с алиасами или к базам данных, размещенных в указанных каталогах файловой системы.

! ! !

ВНИМАНИЕ! Настоятельно рекомендуется установить этот режим и сделать доступным средство алиасов баз данных. Информацию об алиасах базы данных см. в главе 4.

. ! .

* ExtemaiFiieAccess — заменяет параметр EXTERNAL_FILE_DIRECTORY, введенный в версии 1,0. Этот параметр обеспечивает три уровня безопасности для External Files (внешние файлы — текстовые файлы фиксированного формата, к которым возможен доступ, как и к таблицам базы данных). Если вы переносите базу данных, в которой определены внешние файлы таблиц, вам нужно установить этот параметр для версии 1.5, потому что он отключен по умолчанию. Конфигурация необязательная, тем не менее рекомендуется для версии 1.0.x.

* UDFAccess — предназначен для защиты местоположения кода внешних модулей. Он заменяет не только необязательный параметр версии 1.0.x externai_function_ directory, но также и форму представления значения. Firebird 1.5 инсталлируется с отключенным по умолчанию доступом к библиотекам внешних функций, в то время как большинство серверов до этого давали полный доступ.

* TempDirectories (TMP_DIRECTORY в версии 1.0.x)- конфигурирование этого параметра является одним из способов задания размещения временного пространства сортировки для сервера, указав местоположение на диске. Синтаксис Firebird 1.5 отличается от синтаксиса Firebird 1.0.x.

Другие полезные параметры

Следующие параметры могут быть полезными в некоторых аппаратных конфигурациях.

* cpuAffinityMask (CPU_AFFINITY в версии 1.0.x)- может быть использован для назначения процессоров, которые Суперсервер в Windows будет использовать на машинах SMP. Эта проблема известна как эффект «see-saw», когда операционная система постоянно переключает выполнение Суперсервера между процессорами на некоторых машинах SMP. Свойство CPU должно быть установлено для одного процессора, если вам встретилась такая проблема.

По умолчанию маска свойств устанавливается для использования первого процессора в массиве.

* LockMemSize- параметр специфичен для Классических серверов; он определяет количество байтов разделяемой памяти, которая отводится для таблицы памяти, используемой менеджером блокировки. Вам может понадобиться изменить это количество, если вы встретите в Классическом сервере ошибку «Lock manager is out of room» (Менеджеру блокировки не хватает памяти). В связи с этой проблемой см. также параметр LockHashsiots.

* sortMemBiocksize и sortMemOpperLimit — эти два параметра были добавлены в версию 1.5, чтобы позволить устанавливать и ограничивать объем оперативной памяти, которую использует сервер при внутренней сортировке. Для Классического сервера этот размер по умолчанию слишком велик, чтобы поддерживать достаточно большое количество соединений.

* DummyPacketinterval(DUMMY_PACKET_INTERVAL в 1.0.x)- параметр — пережиток 16-битовых систем; он может стать причиной проблем в 32-битовых Windows. Это был старый параметр времени ожидания InterBase, предполагалось устанавливать количество секунд (целое число), в течение которых сервер должен был ожидать от клиента сообщений, после чего сервер должен был посылать пустой пакет для получения подтверждения. По умолчанию он установлен в 0 для Firebird 1.5(неактивен) и в 60 для Firebird 1.0.x. Он должен быть неактивным (установленным в 0) для всех систем Windows. Также настоятельно рекомендуется отключать его для других операционных систем^[5].

* RemoteBindAddress — по умолчанию могут соединиться клиенты из любой сети, из которой сервер принимает трафик. Этот параметр позволяет связать сервис Firebird с исходными запросами через один IP-адрес (например, сетевая карта) и отклонять запросы соединения от любых других сетевых интерфейсов. Это помогает решать проблемы некоторых сетей, где сервер является хостом для нескольких подсетей. Не поддерживается в версии 1.0.x.

* compieteBooieanEvaiuation — параметр может быть использован для преобразования логики вычисления логических значений в виде сокращенного вычисления булевских выражений, используемой в Firebird 1.5 и выше, в полное вычисление булевских выражений, используемое в Firebird 1.0.x.

* oldparameterordering- восстанавливает старый способ обработки порядка параметров для запросов с подзапросами — сначала параметры подзапроса, затем параметры внешнего запроса. Firebird 1.5 по умолчанию обрабатывает параметры в точном порядке их следования, что может быть несовместимо со старыми версиями различных компонентов доступа, которые ориентировались на поведение InterBase/Firebird 1.0.

Пора дальше

Теперь нам больше ничего не осталось, кроме как соединиться с базой данных и начать выполнять серьезные эксперименты. Глава 4, последняя в нашем «учебном лагере», даст вам возможность соединиться с примером базы данных или с любой другой совместимой с Firebird базой данных, которая может находиться на вашем сервере.

ГЛАВА 4. Основные операции.

Теперь у вас есть установленный сервер Firebird, что дальше? Эта глава быстро обучит вас основам Firebird.

Запуск Firebird на Linux/UNIX

Суперсервер

Каталог инсталляции по умолчанию /opt/firebird. В каталоге /bin находится в двоичном формате сервер Firebird fbserver (ibserver для Firebird 1.0.x), который запускается как процесс-демон в Linux/UNIX. Он запускается автоматически после инсталляции посредством RPM или скрипта и каждый раз при перезагрузке сервера запуском скрипта демона firebird, находящегося в /etc/rc.d/init.d (или /etc/init.d в SuSE), который вызывает утилиту командной строки Firebird Manager — fbmgr.bin. Firebird Manager может быть использована из командной строки для запуска и остановки процесса вручную.

Запуск сервера

Если вы по разным причинам запустили Firebird вручную, соединитесь с ним как пользователь root или firebird. Запомните, какую учетную запись вы использовали при запуске fbserver, потому что все созданные объекты будут принадлежать пользователю с этой учетной записью. Если позже другой пользователь запустит процесс с использованием другой учетной записи пользователя, то эти объекты будут ему недоступны.

Настоятельно рекомендуется создать системного пользователя с именем firebird и запускать сервер Firebird с этой учетной записью.

Для запуска процесса выполните из командной строки следующую команду:

./fbmgr.bin -start -forever

Для версий Firebird, предшествующих 1.5, выполните:

./ibmgr -start -forever

Переключатель -forever означает, что Guardian будет управлять запуском.

При использовании Guardian процесс сервера будет заново запущен, если он по каким-либо причинам завершится аварийно.

Для запуска сервера без использования Guardian введите:

./fbmgr.bin -start -once

Для версий Firebird, предшествующих 1.5, выполните:

./ibmgr -start -once

Переключатель -once означает, что если сервер будет аварийно завершен, перезапустить его можно будет только вручную.

Остановка сервера

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

Переключатель -shut отменяет все текущие транзакции и прекращает работу сервера немедленно.

Вам не требуется быть подключенным как пользователь root для остановки сервера Firebird fbmgr, но вы должны иметь полномочия пользователя SYSDBA. Выполните следующую команду.

./fbmgr.bin -shut -password <пароль SYSDBA>

Используйте команду для версий, предшествующих 1.5:

./ibmgr.bin -shut -password <пароль SYSDBA>

Управляемое завершение работы

На этой платформе Firebird не имеет утилиты для подсчета количества пользовательских соединений с базой данных для Суперсервера. Если вам нужно предоставить клиентам интервал времени для завершения работы и корректного отключения, завершайте работу индивидуальных баз данных с использованием инструмента gfix с переключателем -shut и одним из доступных аргументов для управления отключением. (См. разд. «Останов базы данных» в главе 39.)

Другие команды fbmgr

Синтаксис

Из командной строки:

./fbmgr.bin -команда [-режим [параметр] …]

Альтернативно вы можете стартовать интерактивную сессию fbmgr или ibmgr из командной строки (например, перейдя в режим с подсказкой). Наберите:

./fbmgr <нажмите Return/Enter>

для того чтобы перейти к следующей подсказке:

FBMGR>

В режиме с подсказкой синтаксис команд:

FBMGR> команда [-режим [параметр] …]

Например, вы можете запустить сервер одним из следующих способов. Из командной строки:

./fbmgr -start -password пароль В режиме с подсказкой:

FBMGR> start -password пароль

Переключатели fbmgr

В табл. 4.1 представлен список переключателей fbmgr и ibmgr, доступных из командной строки и из режима с подсказкой.

Таблица 4.1. Переключатели fbmgr/ibmgr

Переключатель	Аргумент	Другие переключатели	Описание
-start	-forever \| once	-user, -password	Запускает fbserver, если он не был еще запущен
-shut		-user, -password	Останавливает fbserver
-show			Показывает хост и пользователя
-user	Имя пользователя		SYSDBA; используется с переключателями -start и -stop, если пользователь системы не является root или эквивалентным ему
-password	Пароль SYSDBA		Используется с переключателями -start и -stop, если пользователь системы не является root или эквивалентным ему
-help			Выводит короткий текст помощи fbmgr
-quit			Используется для выхода из режима с подсказками

Классический сервер

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

Как сервер прослушивает запросы на соединение

Если Классический сервер Firebird был установлен инсталлятором, использующим скрипты или RPM, то файл конфигурации запуска для fb inet server с именем firebird должен быть добавлен в сервисы, о которых знает [x]inetd. В большинстве дистрибутивов Linux этот файл размещается в каталоге /etc/xinetd.d. Чтобы [x]inetd «слушал» запросы на соединение от клиентов для вашего Классического сервера Firebird, скрипт firebird должен находиться в том же каталоге, где стартует процесс [x]inetd.

! ! !

СОВЕТ. Если [x]inetd запущен, и ни одного запроса на соединение клиента не последовало вовсе, проверьте, действительно ли скрипт firebird находится там, где он должен быть. Если нет, то вы можете выделить скрипт firebird.xinetd из файлового комплекта инсталляции, скопировать в нужный каталог и переименовать в firebird. Чтобы [x]inetd «видел» сервис Firebird, остановите и заново запустите [x]inetd.

. ! .

Остановка и запуск [x]inetd и его сервисов

Демон [x]inetd сам является сервисом, который по запросу управляет другими сервисами, например Классическим демоном Firebird. Остановка [x]inetd приведет к тому, что все процессы, которыми он управляет, будут также остановлены. Его запуск или повторный запуск приведет к возобновлению прослушивания запросов и запуску управляемых им процессов.

Если все сервисы в каталоге ../rc.d являются безопасными для остановки, соединитесь как пользователь root и остановите [x]inetd следующей командой из командной строки:

ft service xinetd stop или командой:

# service inetd stop

Если [x]inetd не был сконфигурирован для автоматического перезапуска после остановки, запустите его командой^[6]:

# service xinetd restart

Остановка процесса Firebird

Если вам нужно остановить вышедший из-под контроля процесс Firebird в Классическом сервере, вы можете это сделать. Найдите ошибочный процесс, выполнив команду top из командной строки. Эта утилита отображает список наиболее интенсивно использующих CPU процессов, постоянно обновляя этот список. Любой экземпляр fb inet server с необычным использованием ресурсов должен появиться в этом списке.

Выберите идентификатор (process ID, PID) ошибочного процесса fb_inet_server из самой левой колонки в списке. Вы можете использовать этот PID в команде kill для посылки сигнала ошибочному процессу. Например, для PID 12345 вы можете попытаться остановить процесс, выдав:

# kill 12345

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

# kill -9 12345

! ! !

ВНИМАНИЕ! Проявляйте величайшую осторожность при использовании команды kill, особенно если вы подключились как пользователь root.

. ! .

Запуск сервера Firebird в Windows

Суперсервер

Выполняемая программа Суперсервера Firebird — fbserver.exe. Хотя он может запускаться и как самостоятельная программа, он также может находиться под управлением Guardian — fbguard.exe. Guardian обеспечивает возможность эмулировать автоматический рестарт сервисов в Windows и POSIX, запущенных с переключателем -forever. Если приложение fbserver.exe аварийно завершается, Guardian пытается заново его запустить. Рекомендуется использовать Guardian на хостах, работающих на платформах Windows 95/98 и ME, а также NT/XP, если сервер выполняется как приложение.

В Windows NT и Windows 2000 программа сервера Firebird может выполняться как сервис и как приложение. Инсталляция по умолчанию устанавливает сервер Firebird — и Guardian, если выбран — для автоматического выполнения как сервисы. Вариант выполнения для обоих может быть изменен, чтобы они выполнялись как приложения.

В Windows 95/98, ME и XP Home Edition Firebird может выполняться только как приложение. Если Firebird выполняется как приложение, на панели задач появляется соответствующая иконка. Некоторые задачи администрирования могут быть выполнены вручную при щелчке правой кнопкой мыши на этой иконке.

Выполнение Firebird как сервиса в Windows NT, 2000 и XP

Если данный компьютер используется как сервер БД, то вам настоятельно рекомендуется выполнять сервер Firebird как сервис.

! ! !

ПРИМЕЧАНИЕ. Пользователи, выполняющие миграцию с InterBase 6.0 или более раннего, должны обратить внимание, что не требуется выполнения Firebird как приложения на хост-машинах SMP, чтобы установить наличие только одного процессора. Опция сервиса Firebird по использованию количества процессоров содержится в файле конфигурации. Более подробную информацию см. в разд. «Файл конфигурации Firebird» главы 36.

. ! .

Запуск и остановка сервиса вручную

Для остановки сервиса вручную откройте окно командной строки и введите следующую команду:

NET STOP FirebirdServer

Дня старта или рестарта сервера вручную введите команду:

NET START FirebirdServer

! ! !

ВНИМАНИЕ! Поскольку команды NET возвращают сообщения в окно командной строки, не пытайтесь запустить их в окне Выполнить (Run) через кнопку Пуск (Start).

. ! .

Использование утилиты instsvc

Альтернативный, «родной» для Firebird способ запуска и остановки сервисов Firebird и Guardian — использование утилиты instsvc.exe, которая находится в каталоге bin в корневом каталоге Firebird. Утилита instsvc.exe применяется системой для запуска сервиса Firebird- и Guardian, если выбран- когда выполняется первоначальная загрузка хост-сервера. Поскольку с самого начала не ожидалось частого использования ее людьми — это команда в стиле DOS, содержащая переключатели.

! ! !

ПРИМЕЧАНИЕ. Firebird 1.5 содержит дополнительный необязательный переключатель для соединения, чтобы позволить скриптам инсталлятора добавить возможность создания «реального пользователя»- подключенного пользователя для установки сервиса при загрузке системы. Это рекомендуется сделать, т. к. скрипты создают пользователя Firebird с ограниченными привилегиями; соответственно устанавливается инсталляция сервиса. (См. разд. «Защита, основанная на платформе» в главе 33.)

. ! .

Останов и рестарт сервиса с использованием instsvc

Откройте окно командной строки и перейдите к каталогу bin, находящемуся в корневом каталоге установки Firebird. Для останова сервиса Firebird введите:

C:Program FilesFirebirdFirebird_1_5bin> instsvc stop

Для старта (рестарта) сервиса Firebird используйте одну командную строку, изменив, при необходимости, приоритет процесса:

C:Program FilesFirebirdFirebird_1_5bin> instsvc start

[-boostpriority | -regularpriority]

! ! !

ПРИМЕЧАНИЕ. Эти команды не выполняют, соответственно, деинсталляцию и инсталляцию сервиса.

. ! .

Апплеты Firebird Manager

Когда Firebird выполняется как сервис, небольшое количество административных задач, включая останов и рестарт, может быть решено с использованием апплета Firebird Manager на Панели управления. Самый простой апплет инсталлируется при установке Firebird. Более сложные апплеты, включая версии языков, можно загрузить из Firebird CVS с сайта SourceForge или с различных сайтов, связанных с Firebird.

Выполнение Firebird как приложения на платформах Windows

Если сервер Firebird выполняется как приложение, вы должны увидеть иконку в системной области на серверной машине, как показано на рис. 4.1. Вид иконки в системной области зависит от того, запущен ли только сервер, или вы управляете его выполнением с помощью Guardian. Рекомендуется использовать Guardian при выполнении Суперсервера как приложения и исключить его при выполнении Классического сервера.

Рис. 4.1. Иконка на системной панели

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

Запуск сервера как приложения вручную

Если Суперсервер не запущен, или Классический сервер не инициализирован, он может быть запущен вручную при выборе в меню Firebird — Пуск | Все программы | Firebird (Start | Programs | Firebird).

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

Суперсервер

Программа Guardian называется fbguard.exe в Firebird 1.5 и idguard.exe в более ранних версиях. Используйте следующую команду для старта Guardian:

fbguard.exe -a

ibguard.exe -а /* для версии 1.0.x */

Guardian размещает свою иконку на системной панели и автоматически стартует Суперсервер.

Имя программы сервера для Суперсервера fbserver.exe (ibserver.exe в Firebird l.O.x). Для запуска Суперсервера напрямую, минуя защиту Guardian, используйте команду:

fbserver.exe -a

ibserver.exe -а /* для версии 1.0.x */

Сервер стартует и размещает свою собственную иконку на системной панели.

Классический сервер

! ! !

ПРИМЕЧАНИЕ. Этот текст относится к Firebird 1.5 и следующим. Классический сервер для Windows не поддерживается в более ранних версиях.

. ! .

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

Процесс, который является «ушами» для запросов клиентов на соединение с Классическим сервером, является начальным экземпляром программы fb_inet_server.exe. Если начальный экземпляр fb_inet_server.exe не запущен, то не будет возможно соединение клиент-сервер; при попытке соединения вы получите сообщение об ошибке «Unable to connect to the server. Database cannot be found» (Невозможно соединиться с сервером. База данных не может быть найдена).

Когда клиенты соединяются с базой данных, для каждого клиентского соединения запускается один экземпляр fb_inet_server.exe (1.2 Мбайт) и, если сконфигурировано, один экземпляр Guardian на все экземпляры fb_inet_server.exe. Для каждого соединения выполняется собственное выделение кэш-памяти.

Классический сервер и Guardian

Случайно или умышленно, инсталлятор Firebird 1.5.0 имеет небольшую, но приводящую в замешательство аномалию. Если вы не отметите в процессе инсталляции режим Use Guardian (Использовать Guardian), инсталлятор поместит версию для Суперсервера программы Guardian в каталог bin, и он никогда не будет работать с Классическим сервером. Если вы отметите этот режим, то в процессе инсталляции получите сообщение об ошибке, однако инсталлированная версия Guardian будет прекрасно работать с Классическим сервером. Вы можете проверить, правильная ли у вас версия, попытавшись запустить Guardian. Если вы увидите диалоговое окно сообщения об ошибке, содержащее слово «fbserver», значит, вы не выбрали поддержку Guardian в процессе инсталляции.

В любом случае Guardian является лишним для Классического сервера. Вы ничего не потеряете, если не будете его инсталлировать. Я рекомендую игнорировать Guardian для Классического сервера.

Для запуска начального экземпляра Классического сервера как приложения вручную вызовите окно командной строки, перейдите в каталог bin и наберите:

fb_inet_server.exe -a

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

Вы можете альтернативно выбрать режим Use Guardian в процессе инсталляции. Вы также можете стартовать Guardian из того же каталога:

fbguard.exe -с -a

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

Останов сервера

Останов сервера- операция, которая по-разному воздействует на Суперсервер и Классический сервер.

Суперсервер

Щелкните правой кнопкой мыши по иконке Guardian или сервера и выберите в контекстном меню Shutdown (Остановить). Если выполняется Guardian, то сначала он остановит сервер, а затем закроется сам. Подключенные в этот момент пользователи потеряют всю неподтвержденную работу.

Классический сервер

В большинстве случаев нет необходимости «останавливать» Классический сервер. Выбор варианта Shutdown в контекстном меню иконки сервера предотвратит новые соединения с сервером, но это не будет воздействовать на подключенные процессы.

! ! !

ПРИМЕЧАНИЕ. Щелчок мышью по варианту Shutdown в контекстном меню Guardian ничего не выполняет.

. ! .

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

Алиасы базы данных

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

aliases.conf

Средство алиасов включает файл конфигурации aliases.conf. Он находится в корневом каталоге вашей инсталляции сервера и не должен перемещаться оттуда.

Переносимость

До реализации 1.5 все клиентские приложения соединялись с сервером, используя строку соединения, которая включала абсолютный путь к серверу. Формат абсолютного пути меняется в зависимости от того, выполняется ли сервер под Windows или на POSlX-совместимой платформе (Linux, UNIX и т.д.), а для серверов под Windows еще и от того, какой вид сетевого соединения используют клиенты — TCP/IP или NetBEUI.

Предположим, у вашего сервера имя hotchicken. Если сервер выполняется на POSIX- совместимой платформе; клиенты TCP/IP будут соединяться с базами данных, используя строку соединения следующего формата:

hotchicken:/opt/databases/Employee.fdb

Если же сервер работает под Windows, клиенты TCP/IP должны соединяться, используя другой формат пути:

hotchicken:D:databasesEmployee.fdb

Средства алиасов базы данных делают эту разницу для клиентов TCP/IP прозрачной. Абсолютный путь строки соединения помещается в файл алиасов, связывая этот путь с простым именем алиаса. Например, в файле aliases.conf для сервера под Linux наш пример может быть сохранен как

dbl = /opt/databases/Employee.fdb

Для сервера в Windows, инсталлированного для клиентов TCP/IP, это может быть

dbl = D:databasesEmployee.fdb

Независимо от того, где установлен сервер — под Windows или POSIX — строка соединения для клиентов становится одинаковой:

hotchicken:dbl

Тем не менее это средство не является столь изящным, если вы хотите сделать строку соединения вашего приложения прозрачной как для соединений TCP/IP, так и NetBEUI. Нотация UNC для сервера под Windows для клиентов NetBEUI предполагает совместимость, однако если алиас базы данных идентичен, то серверная часть не является переносимой:

\hotchickendbl в сравнении с:

hotchi cken:dbl

Управление доступом

Основное преимущество средства алиасов в том, что оно может быть использовано в комбинации с параметром DatabaseAccess = NONE из файла firebird.conf для ограничения доступа к файлам баз данных — доступ разрешен только к файлам, указанным в aliases.conf.

Алиасы баз данных появились в Firebird 1.5. Для их использования отредактируйте файл aliases.conf в корневом каталоге инсталляции Firebird, используя текстовый редактор, такой как Блокнот (в Windows) или V1 (Linux).

Структура файла aliases.conf

Инсталлированный файл aliases.conf выглядит приблизительно таким образом:

# List of known database aliases

# ———————————————

# Examples:

# dummy = c:datadummy.fdb

Как и во всех файлах конфигурации Firebird, символ # является маркером комментариев. Для конфигурирования алиаса просто удалите символ # и замените строку dummy на соответствующий путь к базе данных:

# fbdbl и aliases.conf находится на сервере Windows:

fbdbl = c:Firebirdl5sampleEmployee.fdb

# fbdb2 и aliases.conf находится на сервере Linux

fbdb2 = /opt/databases/killergames.fdb

При каждом запросе на соединение, содержащем путь, заданный в формате алиаса, сервер обращается к файлу aliases.conf. Вы можете редактировать aliases.conf и когда сервер выполняется. Изменения не будут влиять на текущие соединения, но новые соединения будут использовать новые или измененные алиасы.

Соединение с использованием алиаса пути к базе данных

Для соединений TCP/IP, использующих предыдущий пример aliases.conf, измененная строка соединения в вашем приложении будет иметь следующий формат:

Имя_сервера:имя_алиаса

Например,

hotchicken:fbdb2

Для соединений Windows Named Pipes строка выглядит следующим образом:

\hotchickenfbdb2

Для локального соединения просто используйте собственный алиас.

Администрирование баз данных

Множество прекрасных графических инструментов — свободно распространяемых и коммерческих- доступны для администрирования баз данных Firebird. Информацию о подобных предложениях см. в приложении 5. Обновляемый каталог поддерживается на страницах Contributed Downloads на http://www.ibphoenix.com.

Firebird поставляется с набором инструментов командной строки для сервера и администрирования баз данных. Обычно они работают одинаково в Linux/UNIX и в командной строке MS-DOS. Помните, что в Linux/UNIX команды, параметры и переключатели являются чувствительными к регистру. В Windows — нет.

Интерактивный инструмент запросов isql упомянут в этой главе и полностью документируется в главе 37. Другие инструменты командной строки описываются в следующих разделах.

fbmgr/ibmgr

fbmgr/ibmgr является командой и интерфейсом командной строки для демона Суперсервера в Linux для запуска и останова Суперсервера Firebird в Linux. Скрипт командной строки fbmgr (ibmgr в версии 1.0.x) предоставляет интерфейс для выполняемого модуля сервера fbmgr.bin (ibmgr.bin в версии 1.0.x). Детальное описание представлено в этой главе.

instsvc.exe

Это интерфейс командной строки сервиса Суперсервера на платформах Windows NT для инсталляции, запуска и останова Суперсервера Firebird в Windows. Детальное описание представлено в этой главе.

gbak

Эта утилита предназначена для резервного копирования и восстановления баз данных. Поскольку она работает на уровне структур и форматов данных, gbak является единственной корректной утилитой для копирования. Она также обнаруживает разрушения базы данных, освобождает дисковое пространство, появившееся в результате удалений, разрешает незавершенные транзакции, позволяет разделять базы данных на несколько файлов. Она также используется для создания переносимой копии с целью восстановления вашей базы данных на другой аппаратной платформе или для обновления ODS (On-Disk Structure) вашей базы данных.

! ! !

ВНИМАНИЕ! Никогда не используйте утилиты копирования файлов типа tar/gzip, WinZip, Microsoft Backup, средства копирования файловой системы или утилиты сторонних разработчиков для копирования и переноса баз данных, если сервер работает или у вас нет твердой уверенности, что база данных не повреждена. Базы данных, которые переносятся как копии файлов, будут содержать неубранный мусор.

. ! .

Подробности использования gbak см. в главе 38.

gsec

Этот инструмент поддержки списка пользователей и их паролей является интерфейсом командной строки для базы данных security.fdb; он управляет записями пользователей на сервере Firebird. Подробности использования gsec см. в главе 34.

gfix

Это набор общих вспомогательных утилит для изменения свойств баз данных, устранения небольших повреждений базы данных, выполнения различных задач чистки и т.д. Утилита также предоставляет средство администратора для отключения конкретных баз данных до завершения работы сервера. Она может быть использована вместе с утилитой gbak для восстановления некоторых типов нарушений в базе данных (см. разд. «Ремонт базы данных» приложения 4).

Подробности использования gfix см. в главе 39.

gstat

Этот инструмент получения статистики собирает и отображает статистические сведения по индексам и данным базы данных. Подробную информацию об использовании gstat см. в разд. «Темы оптимизации» главы 18.

fb_lock_print

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

Подробности использования fb_lock_print см. в главе 40.

Введение в isql

Утилита командной строки isql (Interactive SQL) объединяет инструменты и техники использования SQL для поддержки объектов базы данных, управления транзакциями, отображения метаданных и обработки скриптов определения базы данных. Интерфейс командной строки доступен на всех платформах. Настоящее краткое введение даст вам возможность начать работу по подключению к базе данных и созданию вашей первой базы данных.

Запуск isql

Есть несколько различных способов соединения с базой данных при использовании isql. Один способ- стартовать утилиту из командной строки в интерактивном режиме. Для начала в окне командной строки перейдите к каталогу /bin корневого каталога инсталляции Firebird, где инсталлирована программа isql, и запустите isql следующим образом.

Для сервера POSIX:

[chick@hotchicken]# ./isql <нажмите Return/Enter> Для сервера Windows:

C:Program FilesFirebirdFirebird_1_5bin>isql <нажмите Return/Entei>

Утилита выведет следующее сообщение:

Use CONNECT or CREATE DATABASE to specify a database (Используйте CONNECT или CREATE DATABASE для указания базы данных)

Использование isql

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

Оператор CONNECT

Оператор CONNECT является стандартным оператором SQL для соединения с базой данных. Здесь предполагается, что вы пока не изменили пароль у пользователя SYSDBA. Если вы это уже сделали (что рекомендуется), то используйте ваш пароль пользователя SYSDBA.

Каждый из операторов командной строки в следующих примерах является одним оператором.

Для соединения с сервером Linux/UNIX введите:

SQL> CONNECT ‘hotchicken:/opt/firebird/examples/employee.fdb’ user ‘sysdba’ password ‘masterkey’;

Для соединения с сервером Windows:

SQL> CONNECT

‘WINSERVER:С:Program FilesFirebirdFirebird_1_5examplesemployee.fdb’

user ‘SYSDBA’ password ‘masterkey’;

! ! !

ПРИМЕЧАНИЕ. В Классическом сервере под Linux и в Суперсервере под Windows существует возможность соединения с базой данных локально, например:

CONNECT ‘/opt/firebird/examples/employee.fdb’ — Linux Классический сервер.

CONNECT ‘c:Program FilesFirebirdFirebird_1_5examplesemployee.fdb’ — Windows Суперсервер.

. ! .

Убедитесь, что вы заканчиваете каждый оператор SQL символом точка с запятой (;). Если вы забудете это сделать, то увидите следующее в подсказке продолжения утилиты isql:

CON>

Когда вы увидите подсказку продолжения, просто введите точку с запятой и нажмите клавишу <Enter/Return>. В этот момент isql проинформирует вас, что вы соединены:

DATABASE ‘hotchicken:/opt/firebird/examples/employee.fdb’, User: sysdba SQL>

Если сервер работает под Windows, вы увидите следующее:

DATABASE «WINSERVER:С:Program FilesFirebirdFirebird_1_5examplesemployee.fdb»,

User: sysdba

SQL>

Продолжим играть с базой данных employee.fdb. Вы можете использовать isql для запроса данных, получения информации о метаданных, создания объектов базы данных, выполнения скриптов определения данных и многого другого.

Чтобы вернуться к подсказке командной строки, введите

SQL> QUIT;

Создание базы данных с использованием isql

Существует более одного способа создания базы данных с использованием isql. Здесь приведен один простой способ интерактивного создания базы данных — тем не менее для работы с серьезной базой данных вы должны создавать и поддерживать объекты метаданных, используя скрипты определения данных (они также называются скриптами DDL, скриптами SQL, скриптами метаданных и скриптами схемы). Эта тема детально рассматривается в разд. «Скрипты схемы»главы 14.

Если сейчас вы соединены с базой данных через утилиту isql, отсоединитесь с помощью следующей команды:

SQL> QUIT;

Затем заново стартуйте утилиту без соединения с базой данных. Для сервера Linux:

[chick@hotchicken]# ./isql

Use CONNECT or CREATE DATABASE to specify a database

Для сервера Windows:

С:Program FilesFirebirdFirebird_1_5bin>isql Use CONNECT or CREATE DATABASE to specify a database

Оператор CREATE DATABASE

Теперь вы можете создать вашу новую базу данных интерактивно. Предположим, что вы хотите создать базу данных test.fdb на сервере Windows и сохранить ее в каталоге data на диске D:

SQL> CREATE DATABASE ‘D:datatest.fdb’ user ‘SYSDBA’ password ‘masterkey’;

База данных будет создана, и через некоторое время снова появится подсказка. Теперь вы соединены с новой базой данных и можете продолжать создавать в ней тестовые объекты.

Для проверки того, что база данных действительно существует, введите запрос:

SQL> SELECT * FROM RDB$RELATIONS; <нажмите Enter>

Экран будет заполнен большим количеством данных! Этот запрос выбирает все строки из системной таблицы, в которой Firebird сохраняет метаданные для таблиц. «Пустая» база данных не является пустой — она содержит базу данных, которая будет заполняться метаданными, как только вы начнете в ней создавать объекты.

! ! !

СОВЕТ. Почти все объекты метаданных в базах данных Firebird имеют идентификаторы, начинающиеся с символов «RDB$».

. ! .

Чтобы вернуться назад в подсказку командной строки, введите:

SQL> QUIT;

Полную информации по использованию isql см. в главе 57.

Пора дальше

Часть II рассказывает об архитектуре клиент-сервер. В главе 5 рассматривается терминология и различные модели реализации сетей клиент-сервер. В главах 6 и 7 более подробно рассматриваются серверы и клиенты Firebird соответственно.

ЧАСТЬ II. Клиент-сервер.

ГЛАВА 5. Введение в архитектуру клиент-сервер.

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

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

Ключевой принцип в том, что задача расщепляется — или распределяется — между двумя программными компонентами, которые выполняются независимо на двух физически разделенных компьютерах. Эта модель даже не требует, чтобы компоненты выполнялись в совместимых операционных или файловых системах. Клиент электронной почты должен быть почтовой клиентской программой, которая выполняется под Windows, Mac или любой другой операционной системой, а почтовый сервер обычно выполняется в системах UNIX или Linux. Клиентская и серверная программы способны успешно взаимодействовать, поскольку они были спроектированы функционально совместимыми.

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

В примере с электронной почтой протокол коммуникации имеет два уровня. Как и система электронной почты, система баз данных клиент-сервер использует стандартный сетевой протокол и перекрывает его другими протоколами специального назначения. Для электронной почты перекрытие (overlay) будет POP3, IMAP и SMTP; для системы базы данных это протоколы соединения с базой данных, безопасности, переноса данных и языка.

Базы данных клиент-сервер в сравнении с файл-серверами

Системы совместного доступа к файлам являются другим примером систем клиент- сервер. Файловые серверы и серверы файловых систем обслуживают запросы клиентов к файлам и файловым системам иногда весьма запутанными способами. Примеры этому- сервисы NFS, Windows Named Pipes и NetBEUI. Файловый сервер предоставляет клиентам доступ к файлам так, что клиентская машина может читать и писать в памяти сервера, как если бы операции ввода/вывода проводились в ее собственной локальной системе памяти.

Настольная система управления данными имеет недостаток — собственная внутренняя реализация управления запросами ввода/вывода, поступающими из сети, сама является клиентом файлового сервера. Когда сервер получает запросы на ввод/вывод от своих клиентов, он полагается на средства управления операционной системы для обеспечения центрального блокирования и организации очереди, необходимые для управления конфликтными запросами.

Такие файл-серверные СУБД не являются клиент-серверными системами баз данных. Программное обеспечение клиента и СУБД- клиенты сервера совместного доступа к файлам. Хотя входной и часто выходной потоки являются до известной степени управляемыми программой СУБД, физическая целостность данных находится под управлением сервисов файловой системы.

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

Характеристики СУБД клиент-сервер

Масштабируемость

Появление сравнительно недорогих компьютерных сетей между 1980-ми и 1990-ми годами вызвало увеличенный спрос на масштабируемые информационные системы с дружественным пользователю интерфейсом. Программное обеспечение электронных таблиц и настольных баз данных, а также графический интерфейс дали пользователям, не являющимся специалистами, понимание мощности использования компьютеров. Когда совместное использование файлов в сетях и различного вида программного обеспечения стало стандартной практикой на больших предприятиях, заказчики запросили большего. Настольные и основанные на локальных сетях (Local Area Network, LAN ) системы управления данными также стали использоваться и в весьма малых бизнесах. Сегодня практически немыслимо проектировать информационную систему предприятия для монолитной модели на мэйнфрейме с текстовым терминалом.

Масштабируемость оценивается в двух размерностях: горизонтальной и вертикальной. Горизонтальная масштабируемость — способность системы добавлять дополнительных пользователей без воздействия на возможности программного обеспечения или используемые ресурсы. Вертикальная масштабируемость связана с тем, что будет сделано для переноса системы на более простые или более сложные платформы и конфигурации аппаратных средств в ответ на изменение требований нагрузки и доступа. Диапазон меняется от нижнего уровня — например, сделать систему доступной для пользователей мобильных устройств — до верхнего уровня, который не имеет концептуальных ограничений.

Функциональная совместимость

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

Защита данных

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

Распределение функций

Модель клиент-сервер позволяет отдельным фрагментам работы системы быть эффективно распределенными между компонентами аппаратуры и программного обеспечения. Сервер базы данных заботится о хранении, управлении и поиске данных, а через хранимые процедуры, триггеры и другие вызываемые процессы он обеспечивает большое количество возможностей обработки данных системы. Процесс клиента является «острием» приложений, транслируя их запросы в структуры коммуникации, которые формируют протоколы для доступа к базам данных и к данным.

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

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

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

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

Двухуровневая модель

Рис. 5.1 иллюстрирует классическую двухуровневую модель клиент-сервер. Промежуточный уровень, который может присутствовать или отсутствовать, представляет собой драйвер, такой как ODBC, JDBC, PHP, или компонент доступа к данным, который интегрирован с программным кодом приложения. Возможны и другие уровни на клиентской стороне. Приложения также могут быть написаны с использованием прямого доступа к API без промежуточного уровня.

Рис. 5.1. Двухуровневая модель клиент-сервер

Многоуровневая модель

Увеличение возможностей масштабирования и требования большей функциональной совместимости приводят к модели с большим количеством уровней, как показано на рис. 5.2. Клиентский интерфейс перемещается в центр модели; он объединяется с одним или более уровнями сервера приложений. В этом центральном комплексе будут расположены средства промежуточного уровня и сетевые модули. Уровень приложения становится некоторым видом суперклиента базы данных — иногда обслуживая множество серверов баз данных — и сам становится Proxy-сервером (сервером-посредником) для запросов к базам данных от приложений. Он может быть размещен на том же аппаратном оборудовании, что и сервер базы данных, но также может выполняться и на своем оборудовании.

Рис. 5.2. Многоуровневая модель клиент-сервер

Стандартизация

Признанные стандарты функциональной совместимости аппаратного и программного обеспечения, и особенно языка запросов и описания метаданных, являются характерной чертой систем баз данных клиент-сервер. Развитие систем реляционных баз данных и консолидация стандартов SQL более двух десятилетий было и остается неразделимым. Абстрактная природа хорошо спроектированных систем реляционных баз данных вместе с их относительной нейтральностью по поводу выбора языка приложения для «предварительной обработки» гарантируют, что реляционные СУБД продолжают занимать свое место в качестве предпочтительной архитектуры систем клиент-сервер.

Тем не менее это не отменяет другие архитектуры. Хотя в настоящее время объекты систем баз данных продолжают оставаться тесно связанными с языками приложения, объектно-реляционные архитектуры становятся значительным посягательством на реляционные традиции. Самые последние стандарты SQL представляют некоторые положения по стандартизации объектно-реляционных методов и синтаксиса. Когда люди начинают требовать стандарты для технологий, обычно это хороший индикатор того, что технология может быть востребованной в скором времени.

Проектирование систем клиент-сервер

Факт, что системы клиент-сервер должны быть спроектированы для использования в сетях. Для новичков часто бывает потрясением открытие того, что «молниеносно выполняемая» задача, которая работала в приложении под Paradox или Access, занимает весь день после конвертирования в клиент-серверную реляционную СУБД.

«Что-то не так в Firebird, — говорят они. — Это не может быть код моего приложения — потому что я не изменял ничего! Это не может быть результатом моего проектирования базы данных — потому что то же проектирование было безупречным многие годы!» Знаменитые последние слова.

Основа проектирования клиентов для настольных систем резко отличается от проектирования удаленных клиентов в архитектуре клиент-сервер. Обязательный интерфейс просмотра в настольных системах, где отображаются «200 000 записей за один раз», создал крупную отрасль RAD разработки компонентов DBGrid, связанных с данными (data-aware components). Разработчику никогда не нужно думать о том, какое количество человек в состоянии просмотреть 200 000 записей в день, пусть только одним взглядом!

Эти компоненты в RAD, которые выполнили такую замечательную работу

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

Действительно, общим является то, что на проектирование базы данных наиболее сильно влияет восприятие клиентского интерфейса — «Мне нужна таблица, похожая на эту электронную таблицу!»- а не элегантная мудрость абстрактной модели данных.

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

Абстракция хранимых данных

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

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

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

* Большие составные символьные ключи, составленные из столбцов реальных данных.

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

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

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

Отбрасывание идеологии электронных таблиц

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

Перенос таких старых баз данных в систему клиент-сервер обычно требует большего, чем создание программы конвертирования данных. Выполните ваше конвертирование и будьте готовы рассматривать объекты вашей базы данных как основу для дальнейшей работы. Запланируйте выполнить заново анализ и новое проектирование полученного абстрактного стиля базы данных в структуры, которые будут хорошо работать в новом окружении. В Firebird очень просто создать новые таблицы и записать в них данные. Для хранения используйте простые ключи; преобразовывайте структуры больших таблиц в группу связанных нормализованных отношений; переносите группы повторяющихся столбцов в отдельные таблицы; изменяйте структуры ключей, которые уменьшают уровень зависимостей; устраняйте дублирование данных и т.д.

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

Таблицы для вывода

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

Пользовательский интерфейс

Клиентские приложения в системе, где информационные сервисы предприятия имеют серверную программу, которая является полнокровной СУБД с мощными возможностями обработки данных, не изменяют вводимые пользователем данные после выполнения синтаксического разбора их исходного вида и упаковывания кода в подготовленные контейнеры — в структуры транспортных функций API. Циклам FOR над сотнями и тысячами строк в клиентском буфере набора данных нет места на клиентском компьютере в системах клиент-сервер.

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

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

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

Модель хранения реляционных данных

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

Первичный ключ

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

Реляционные СУБД предполагают, что каждая строка в каждой таблице имеет уникальный столбец для однозначной идентификации строк, для проверки соответствия условиям поиска и для связи элементов данных и потоков^[7].

Отношения

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

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

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

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

«Руки прочь» от доступа к данным

Реляционные СУБД, разработанные для архитектуры клиент-сервер, не предоставляют пользователям прямой доступ к данным. Когда пользовательское приложение хочет выполнить операции над набором данных, оно сообщает клиентскому модулю, чего оно хочет, и клиентский модуль «договаривается» с сервером об удовлетворении этой потребности. Если запрос отвергается по какой-то причине, то именно клиентский модуль сообщает «плохую новость» приложению.

Если приложение запрашивает набор данных для чтения, то клиентский модуль берет результат выполнения сервером операции и передает его приложению. Данные, видимые приложению, являются образом состояния исходных данных в базе данных на момент начала «переговоров» между клиентом и сервером. Этот образ, который видят пользователи, отключен — или изолирован — от базы данных. «Момент изоляции» может не совпадать с тем моментом, когда сервер получает запрос. В окружении клиент-сервер, где предполагается, что более чем один пользователь читает и пишет данные, каждый запрос имеет контекст.

Множество пользователей и параллельность

СУБД разработана для того, чтобы обеспечить работу множества пользователей с образами хранимых данных и, чтобы можно было использовать изменяющие запросы, которые могут влиять на работу других пользователей. В этой ситуации нужны способы управления параллельностью. Параллельность — это набор условий, в которых предусмотрена ситуация, когда запросы двух или более пользователей изменяют одну и ту же строку таблицы в одно и то же время (т. е. параллельно). Развитые СУБД, такие как Firebird, реализуют некую схему, при которой каждый запрос выполняется в параллельном контексте. Стандартный термин для такого параллельного контекста транзакция- не путайте с «бизнес-транзакциями», которые часто реализуются в приложениях баз данных.

Транзакции

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

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

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

! ! !

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

. ! .

Транзакции настолько важны в системах клиент-сервер, что в настоящем руководстве им посвящены три главы. 25, 26 и 27.

Пора дальше

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

ГЛАВА 6. Сервер Firebird.

Сервер Firebird — это программа, которая выполняется на узле хоста в сети, и слушает клиентов с порта коммуникации. Она обслуживает запросы множества клиентов к множеству баз данных. Суперсервер (Superserver) является многопоточным процессом, который запускает новый поток для каждого соединившегося клиента. В модели Классического сервера (Classic server) новый процесс запускается для каждого соединения.

Серверы Firebird могут выполняться почти на любом оборудовании персональных компьютеров и принимать клиентские соединения от приложений, выполняющихся в совершенно других операционных системах. С одной стороны, небольшой и легкий дистрибутив сервера может быть установлен на устаревшем оборудовании, даже для старых процессоров Pentium в операционной системе Windows 95 или в минимальных системах Linux. С другой стороны, серверы Firebird выполняются на распределенном оборудовании, управляя базами данных размерами в терабайты^[8].

Конечно, нереально планировать информационную систему предприятия, выполняющуюся под Windows 95. Тем не менее проще простого запустить минимально сконфигурированный сервер, а по необходимости в дальнейшем масштабировать его как по вертикали, так и по горизонтали. Серверы Firebird существуют в двух вариантах — Суперсервер и Классический сервер для удовлетворения различных потребностей пользователя. Оба могут быть масштабированы как вверх, так и вниз для обработки от самых простых до наиболее сложных конфигураций.

Программное обеспечение сервера Firebird эффективно использует системные ресурсы хост-компьютера. Суперсервер использует приблизительно 2 Мбайта памяти. Каждое клиентское соединение Суперсервера добавляет примерно 115 Кбайт к используемой сервером памяти — меньше или больше в зависимости от характеристик приложений клиента и способа проектирования базы данных. Каждое соединение Классического сервера запускает собственный серверный процесс, требующий приблизительно 2 Мбайта памяти.

Требуемая серверу кэш-память зависит от конфигурации и от выбранного варианта Firebird. Обычная конфигурация кэша для сети при одновременно работающих 20-40 пользователях, скорее всего, будет 16, 32 или 64 Мбайта для Суперсервера, использующего общий пул для всех соединений. Для каждого Классического сервера назначается статический кэш с размером по умолчанию 75 Кбайт. Серверы версии 1.5 также будут использовать RAM для ускорения сортировки, если память доступна. Требуемое дисковое пространство для минимальной инсталляции Firebird составляет от 9 до 12 Мбайт в зависимости от платформы. Дополнительное дисковое пространство требуется для временного хранения данных в процессе выполнения операций, дополнительная память также требуется для кэширования страниц базы данных. Эта память конфигурируется в соответствии с запросами обработки данных и вероятного объема и типа обрабатываемых данных.

Роль сервера

Работа сервера включает:

* управление хранением данных базы данных и выделение дискового пространства;

* управление всеми транзакциями, запущенными клиентами, гарантирование, что каждая получит и сохранит непротиворечивый образ постоянно хранимых данных, требуемых клиенту;

* управление подтверждением транзакций, данными и сборкой мусора;

* поддержку блокировок и статистики для каждой базы данных;

* обработку запросов на добавление, изменение или удаление строк и поддержку текущих и устаревших версий записей;

* поддержку метаданных каждой базы данных и обслуживание запросов клиентов по созданию новых баз данных и объектов базы данных, изменение структур, проверку и компиляцию хранимых процедур и триггеров;

* обслуживание клиентских запросов на получение результирующих данных и выполнение хранимых процедур;

* маршрутизацию сообщений для клиентов;

* поддержку кэшированных данных для хранения часто используемых наборов данных и индексов;

* отдельную поддержку безопасности баз данных для проверки доступа пользователей.

Платформы для операционных систем

Платформы сервера Firebird включают следующие операционные системы, но не ограничиваются только ими.

* Linux, FreeBSD и другие варианты ОС UNIX.

* Платформы Microsoft Windows, поддерживающие сервисы: NT 4, Windows 2000 (сервер или рабочая станция), XP Professional и Server 2003. Операционные системы Windows 9х, ME и XP Home могут быть использованы как сервер, который прослушивает порты протокола TCP, но не Named Pipes (NetBEUI).

* Mac OS X (Darwin).

* Sun Solaris SPARC и Intel.

* HP-UX.

Примеры топологий

Сервер Firebird существует в нескольких «моделях», которые обеспечивают множество режимов масштабирования — от однопользовательского варианта, независимой настольной системы, до мощного сервера.

Двухуровневая архитектура клиент-сервер

На рис. 6.1 изображена гибкая система, где множество серверов Firebird выполняются на платформах с различными операционными и файловыми системами. Здесь присутствует смесь рабочих станций, на которых выполняются удаленные клиенты, каждый на своей платформе. Здесь же существуют шлюзы для других сетей. Сервер Windows обслуживает повседневную обработку деловых данных и располагает большим объемом дискового пространства. Для клиентов Windows возможно общение с сервером Windows с использованием протокола Named Pipes — обычно называемым NetBEUI, — хотя такой протокол должен быть заменен по возможности на TCP/IP.

Сервер Linux может обслуживать системы сетевой защиты, шлюзы, вспомогательные базы данных и другие системы клиент-сервер, включая электронную почту, Интернет и сервисы файлов, такие как NFS и Samba.

Рис. 6.1. Двухуровневая топология клиент-сервер в Firebird

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

Однопользовательская модель

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

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

* Встраиваемый сервер. Никакой сервер не инсталлируется. Сервер находится в DLL, похожей на клиентскую библиотеку, и загружается приложением. Приложение вместе с DLL сервера выполняется как единственный процесс на одно соединение. Когда приложение завершается, то фактически завершается и работа сервера.

Клиент-сервер

В автономной модели клиент-сервер локализованное клиентское подключение к выполняющемуся серверу выполняется с использованием локального протокола. Сервер может прослушивать подключения от удаленных клиентов во время подключенного локального клиента. Рис. 6.2 иллюстрирует этот режим.

Рис. 6.2. Автономные серверы

Первый пример показывает модель локального подключения. В Firebird 1.5 и ниже подсистема IPSERVER моделирует сетевое подключение в том же блоке пространства общения между процессами. В версии 1.5 и выше вместо локального протокола используется более быстрая и надежная подсистема XNET. Функциональный эквивалент локального подключения используется Классическим сервером в POSIX.

В двух других примерах в Windows, Linux или на любой другой поддерживаемой платформе Суперсервер использует локальную «заглушку» (loopback) протокола TCP/IP. Это обычное подключение TCP/IP к специальному IP-адресу 127.0.0.1, который большинство подсистем TCP/IP инсталлирует по умолчанию для локального хоста (localhost). В Linux Классический сервер версии 1.5 может применяться в этом режиме при использовании клиентской библиотеки libfbclient.so.

Встраиваемый сервер

Встраиваемые серверы поддерживаются на платформах Windows и Linux/UNIX, хотя реализация моделей различна. Под Windows библиотека встроенного сервера, который выполняется как единый процесс, называется fbembed.dll. В Linux/UNIX это стандартный режим локального подключения для Классического сервера. Библиотека libfbclient.so запускает один процесс Классического сервера (fb_inet_server или ib inet server) и напрямую соединяется с базой данных. Процесс не является исключительным — удаленные клиенты могут одновременно соединяться с базой данных, используя fbclient.so, другую библиотеку libfbclient.so или fbembed.dll.

Более подробно встроенные серверы обсуждаются в главе 7.

Серверы Firebird в среде DTP

Детальное обсуждение среды распределенной обработки транзакций (Distributed Transaction Processing, DTP) не является целью данной книги. Достаточно сказать, что Суперсервер или Классический сервер Firebird хорошо подходят к различным сценариям DTP.

Open Group, определившая стандарт x/Open для DTP, предоставила три программных компонента для системы DTP. Спецификация XA определяет интерфейс между менеджером транзакций и менеджером ресурсов (Resource Manager, RM). Система имеет один RM-модуль для каждого сервера; требуется каждый RM для регистрации менеджера транзакций.

На рис. 6.3 показано, как сервер Firebird может быть представлен в XA-совместимой среде DTP. Модуль сервера приложения базы данных представляет собой мост между приложениями пользователя высокого уровня и RM, инкапсулирующим соединение XA. RM выполняет роль клиента связи с сервером базы данных для доступа к данным.

Инкапсуляция соединения XA дает возможность разработчику приложения создавать и выполнять операторы SQL в RM. Разграничение транзакций, которое требуется средствам двухфазного подтверждения для всех серверов, регулируется глобальным

монитором обработки транзакций (Transaction Processing Monitor, TPM). Транзакции с несколькими базами данных, находящиеся под управлением менеджера транзакций, выполняются с помощью процесса двухфазного подтверждения. В первой фазе транзакции подготавливаются для подтверждения; во второй фазе транзакции либо полностью подтверждаются, либо откатываются^[9]. TPM проинформирует вызывающий модуль, если транзакция не будет по разным причинам завершена.

Рис. 6.3. Firebird в распределенной среде выполнения транзакций

TPM согласовывает распределенные транзакции в системах множества баз данных, так что одна транзакция может использовать один или более процессов и изменять одну или более баз данных. Монитор хранит информацию обо всех доступных и включенных в транзакции RM.

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

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

Сервер транзакций Microsoft (Microsoft Transaction Server, MTS) с COM+ является одним из таких сценариев. MTS/COM+ обеспечивает среду для объединенных в пул процессов, которая осуществляет использование и управление компонентами бизнес- логики, включая контроль системы, безопасность и мониторинг выполнения. Одной из наиболее значимых возможностей является декларативное управление транзакциями. Транзакции, инициированные в MTS/COM+, управляются координатором распределенных транзакций (Microsoft Distributed Transaction Coordinator, DTC), менеджером ресурсов XA. Родной интерфейс Firebird требует провайдера ODBC или OLE DB, который поддерживает как двухфазное подтверждение транзакций Firebird, так и контекст вызова MTS/COM+^[10].

Терминальные серверы

Firebird успешно используется в средах MTS и IBM Citrix. Во всех случаях используется протокол TCP/IP для соединений по сетевым IP-адресам.

! ! !

ВНИМАНИЕ! Весьма нежелательно инсталлировать на одном и том же узле терминальный сервер и сервер базы данных. Тем не менее в ситуациях, когда сервер приложения выполняется на том же узле, что и сервер базы данных, соединение должно осуществляться с использованием IP-адреса этого узла или по имени localhost.

. ! .

Базы данных

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

Файл базы данных Firebird состоит из блоков, называемых страницами. Размер страницы базы данных может быть 1, 2, 4, 8 или 16 Кбайт; он устанавливается во время создания базы данных. Размер страницы может быть указан при создании, и изменен только во время восстановления базы данных из резервной копии при задании нового значения. Различные базы данных на одном и том же сервере могут иметь различные размеры страниц.

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

Программирование на стороне сервера

Среди мощных средств Firebird по динамическому программированию приложений клиент-сервер существует возможность компилировать на сервере исходные коды в двоичную форму для использования во время выполнения. Такие процедуры и функции выполняются полностью на сервере, возвращая клиентскому приложению при необходимости значения или наборы данных. Firebird предоставляет два стиля программирования на стороне сервера: хранимые процедуры и триггеры. В дополнение к этому внешние функции (или функции, определенные пользователем — User-Defined Functions, UDF) могут быть написаны на языке высокого уровня и стать доступными серверу для использования в выражениях SQL.

Хранимые процедуры

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

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

Триггеры

Триггеры являются особыми процедурами, созданными для определенных таблиц с целью автоматического выполнения в процессе завершения добавлений, изменений или удалений на сервере. Любая таблица может иметь произвольное количество триггеров, которые будут выполняться до или после добавлений, изменений или удалений. Порядок выполнения определяется параметром позиции в объявлении триггера. Триггеры имеют некоторые расширения языка, недоступные для хранимых процедур или в динамическом SQL. Например, контекстные переменные OLD и NEW, при использовании которых в качестве префикса к имени столбца можно получить доступ к существующему (старому, old) и требуемому (новому, new) значению столбца. Триггеры могут вызывать хранимые процедуры, но не другие триггеры.

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

Функции, определенные пользователем

Для сохранения своего малого объема Firebird поставляется с весьма скромным арсеналом встроенных (родных) функций трансформации данных. Пользователи могут писать свои собственные функции на известном им языке, таком как C/C++, Pascal или Object Pascal, для получения аргументов и возвращения единственного результата. Как только внешняя функция (UDF) будет определена в базе данных, она тут же станет доступной как допустимая функция SQL для приложений, хранимых процедур и триггеров.

Firebird поставляет две готовые к использованию библиотеки UDF: ib udf, доступную как для Windows, так и для Linux, и fbudf, доступную в настоящий момент для Windows и Linux в версии 1.5 и доступную только для Windows в версии 1.0.x. Firebird отыскивает UDF в библиотеках, находящихся в каталоге /udf каталога инсталляции или в других каталогах, указанных в параметре udfAccess (версия 1.5) или externai_function_directory (версия 1.0.x) в файле конфигурации Firebird.

Приложения, работающие с несколькими базами данных

В отличие от многих реляционных баз данных приложения Firebird могут быть одновременно соединены более чем с одной базой данных. Клиент Firebird может открывать и иметь доступ к любому количеству баз данных в одно и то же время. Таблицы из разных баз данных не могут быть объединены для получения связанного набора данных, но для комбинирования информации могут использоваться курсоры.

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

Безопасность сервера

Для управления доступом пользователей к серверу Firebird использует базу данных безопасности security.fdb (isc4.gdb в версии 1.0.x). Во время инсталляции эта база данных содержит одного пользователя — SYSDBA.

* В инсталляции Windows пароль пользователя SYSDBA masterkey. Настоятельно рекомендуется немедленно после инсталляции запустить программу gsec.exe (в каталоге инсталляции, подкаталоге /bin) и изменить этот пароль. Это один из наиболее известных паролей в мире баз данных!

* Инсталляторы RPM версии 1.5 для Linux генерируют случайный пароль для SYSDBA и заменяют в базе данных старый пароль masterkey. Этот пароль сохраняется в корневом каталоге инсталляции в текстовом файле с именем firebird.PASSWORD. Если вы собираетесь использовать данный пароль, то удалите этот файл.

Пользователь SYSDBA имеет полные привилегии ко всем базам данных на сервере; в текущей модели безопасности он не может быть изменен. Пользователь root в Linux/UNIX получает привилегии SYSDBA автоматически. Владелец базы данных (пользователь, создавший базу данных) имеет полные права на эту базу данных. Для всех других пользователей доступ к объектам базы данных возможен только через предоставление им привилегий SQL.

Безопасность базы данных

Все пользователи, за исключением тех, кто имеет полные привилегии, должны получить права к каждому объекту, к которому они должны иметь доступ. SQL-оператор GRANT используется для назначения привилегий.

Firebird поддерживает роли SQL. Вначале роль должна быть создана с использованием оператора CREATE ROLE и подтверждена (commit). Группа привилегий может быть назначена роли, а затем роль может быть назначена пользователю. Для использования этих привилегий пользователь должен при соединении с базой данных указывать и имя пользователя, и имя роли.

Более подробную информацию о безопасности баз данных см. в главе 35.

Пора дальше

В главе 7 мы более внимательно рассмотрим клиентскую сторону в архитектуре клиент-сервер Firebird: библиотеку функций, которая предоставляет приложениям такие уровни системы, как средства связи и язык SQL. Если вам нужна помощь в инсталляции удаленного клиента, перейдите к последнему разделу этой главы.

ГЛАВА 7. Клиенты Firebird.

Клиенту на удаленной рабочей станции требуется клиентская библиотека и приложение (программа), которое может взаимодействовать с интерфейсом прикладного программирования (Application Programming Interface, API), объявленным в этой библиотеке.

Клиентская библиотека предоставляет протокол соединения и транспортный уровень, которые ваше клиентское приложение использует для связи с сервером. Стандартная библиотека для клиентов Windows — это Windows DLL. Для клиентов POSIX это совместно используемый объект (библиотека SO). Размер стандартной клиентской библиотеки приблизительно 350 Кбайт.

Некоторые уровни доступа, как, например провайдер Firebird .NET и драйверы JayBird Java, не требуют наличия клиентской библиотеки и напрямую реализуют сетевой протокол. Еще один режим существует во встраиваемом сервере — библиотека, которая объединяет клиентский и серверный экземпляры для использования одним пользователем.

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

Обычно вы будете инсталлировать копию клиентской библиотеки на сервере для использования с некоторыми утилитами командной строки Firebird и/или для различных программ управления, выполняющихся на сервере, которые вы могли бы использовать. Тем не менее многие из этих утилит могут запускаться удаленно. Администратор системы может управлять некоторыми из основных сервисов, предоставляемыми этими утилитами для доступа к ним, через интерфейс управления услугами на хосте.

Что такое клиент Firebird?

Клиент Firebird — это приложение, обычно написанное на языке высокого уровня, которое предоставляет конечному пользователю доступ к средствам и инструментам системы управления базами данных Firebird и к данным, хранимым в базах данных. Интерактивная утилита isql и другие утилиты командной строки в вашем каталоге Firebird /bin являются примерами клиентских приложений.

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

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

Firebird был спроектирован для неоднородных сетей. Клиенты, выполняющиеся в одной операционной системе, могут иметь доступ к серверу на другой платформе операционной системы. Общий случай- наличие рабочих станций под Windows (98 или ME) и Linux, одновременно имеющих доступ к корпоративному серверу, выполняющемуся под Windows NT или Windows 2000, либо под какой-нибудь разновидностью UNIX или Linux.

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

Для разработок Java постоянно поддерживаемые в Firebird драйверы включают JayBird JDBC/JCA-совместимый драйвер Java для гибкого, независимого от платформы интерфейса приложения между множеством открытых и коммерческих систем разработки Java и базами данных Firebird. Открытые и сторонние интерфейсные компоненты и драйверы доступны для множества других платформ разработки, включая Borland Delphi, Kylix и C++ Builder, коммерческие и открытые варианты C++, Python, PHP и DBI::Perl. Для приложений .NET провайдер Firebird .NET постоянно совершенствуется. Контактные адреса и другую информацию см. в приложении 3.

Клиентская библиотека Firebird

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

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

Не смешивайте версии клиента и сервера

Важным является соответствие версии клиентской библиотеки и версии сервера. Используйте клиент версии 1.0.x с сервером версии 1.0.x и клиент версии 1.5 с сервером версии 1.5.

Помните также, что клиент версии 1.5 может быть инсталлирован в тот же каталог, что и клиент 1.0, а может быть поставлен в отдельный каталог. При переустановке новой версии изучите файл README и документацию по инсталляции (размещается в корневом каталоге инсталляции Firebird и в подкаталоге /doc на сервере), чтобы выяснить, какая информация данной книги устарела.

Все клиентские приложения и промежуточное программное обеспечение должны использовать API для доступа к базам данных Firebird. API Firebird имеет обратную совместимость с API InterBase. Документ «InterBase API Guide» (Руководство no API InterBase), доступный в Borland, содержит полное описание API для разработки высокопроизводительных приложений. Более поздние возможности документированы в официальных замечаниях по релизу Firebird и в ограниченном объеме в заголовочных файлах, поставляемых с Firebird^[11].

Разработка приложений

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

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

Firebird реализует множество операторов SQL, синтаксис которых имеет высокий уровень соответствия с признанным стандартом SQL-92. API Firebird предоставляет полные структуры для компоновки операторов SQL и связанных параметров и для получения приложениями результатов.

Динамические приложения клиент-сервер

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

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

Клиентские приложения используют динамический SQL (DSQL) для создания запросов во время выполнения. Клиент Firebird объявляет API как библиотеку функций, которые передают сложные структуры записей, формируют протокол на уровне данных для связи между приложением и сервером.

! ! !

ПРИМЕЧАНИЕ. Программирование с использованием API — большая тема. Ее описание выходит за рамки данной книги. Но поскольку динамический SQL сам не предоставляет некоторых функций, здесь описываются отдельные функции API, чтобы помочь вам понять, как драйверы и интерфейсные компоненты делают их доступными в соответствующих средах проектирования.

. ! .

Ядро API Firebird

Программирование с использованием API необходимо при написании драйверов для создания сценариев в таких языках, как PHP и Python, и при разработке объектно- ориентированных классов доступа к данным для объектно-ориентированных языков типа Java, C++ и Object Pascal. Приложения также могут быть написаны с прямыми вызовами функций API без посредничества драйверов. Эти приложения «прямого API» могут быть мощными, гибкими, быстро-выполняемыми, небольшого размера и с прекрасным управлением распределением памяти.

Функциональные категории ядра API

Функции API (все их имена начинаются с isc) делятся на восемь категорий.

* Соединение с базой данных и отсоединение от базы данных — например,

isc_attach_database().

* Запуск, подготовка, подтверждение и откат транзакций — например,

isc_start_transaction().

* Вызовы выполнения операторов — например, isc_dsql_describe().

* Вызовы BLOB — например, isc_biob_info().

* Вызовы для массивов — например, isc_array_get_slice().

* Безопасность базы данных — например, isc_attach_database().

* Информационные вызовы — например, isc_database_info().

* Преобразования даты и целых — например, isc encode date().

Более подробную информацию по программированию прямого API см. в «API Guide» документации по InterBase 6, опубликованной фирмой Borland.

Интерфейсы приложений при использовании API

Приложения, которые используют общие интерфейсы типа ODBC или JDBC, основаны на операторах DSQL, располагающихся ниже пользовательских интерфейсов, таких как построители запросов и др.

В связи с увеличением числа инструментов быстрой разработки приложений (Rapid Application Development, RAD) за последнее десятилетие инкапсуляция функций API в «обертку» классов и компонентов разработчикам под Firebird предоставлены разнообразные привлекательные средства создания приложений.

Объектно-ориентированные классы

Объектно-ориентированные классы и компоненты доступа к данным инкапсулируют вызовы функций и структуры данных API. Все они имеют свойства и методы, которые анализируют и выполняют синтаксический разбор запрашиваемых операторов, а также управляют возвращаемыми результатами. Богатые классы включают методы и свойства, которые поддерживают специальные возможности Firebird, такие как распределенные транзакции, обработка массивов, параметризованные операторы. Большинство наборов компонентов реализует, по меньшей мере, один класс компонента- контейнера для буферизации одной или более строк, возвращаемых клиенту в виде результирующего набора. Некоторые реализуют продвинутые техники, такие как прокручивание курсоров, «живые данные», обратные вызовы и управление транзакциями.

Драйвер JayBird Туре 4 («родной») JDBC поставляет интерфейс, предназначенный для независимой от платформы разработки на Java с использованием Firebird. Некоторые наборы компонентов устанавливаются в качестве интерфейса разработчиками, использующими Delphi, Kylix и C++ Builder для написания клиентов баз данных Firebird. Двумя лучшими наборами компонентов являются IB Objects и FIBPlus. Доступны некоторые другие наборы компонентов, осуществляющие минимальную поддержку возможностей Firebird. Более подробную информацию см. в приложении 3.

Встроенные приложения Firebird

Firebird предоставляет две различные встраиваемые модели: приложения встроенного SQL (Embedded SQL) и встраиваемые серверы.

Приложения встроенного SQL

В этой модели программа приложения включает в себя интерфейс клиент-сервер и уровень приложения конечного пользователя- все в одном исполняемом модуле. Операторы SQL находятся непосредственно в исходном коде программы, написанной на С, C++ или другом языке программирования. Затем исходный код приложения обрабатывается препроцессором gpre, который отыскивает блоки кода, содержащие операторы SQL. Он подставляет макровызовы функций, которые функционально эквивалентны функциям динамической библиотеки API. Когда работа препроцессора завершается, все выполненные преобразования операторов SQL компилируются вместе с приложением. Такие операторы перед компилированием называются статическим SQL.

В таком стиле приложений доступно специальное расширенное подмножество исходных команд, похожих на SQL. Встроенный SQL (Embedded SQL, ESQL) предоставляет программисту простой язык высокого уровня в виде «черного ящика», в то время как gpre выполняет всю работу по преобразованию сложных языковых структур в эквивалентные вызовы API. Эти статические операторы дают незначительное увеличение скорости по сравнению с динамическим SQL, поскольку не требуют дополнительных затрат на синтаксический разбор и интерпретацию операторов SQL во время выполнения.

Язык и техники ESQL подробно не обсуждаются в данной книге. Документ «InterBase Embedded SQL Guide» («Руководство по встроенному SQL InterBase», EmbedSQL.pdf), доступный в Borland, содержит описания, необходимые для разработки встроенных приложений Firebird.

Приложения встраиваемого сервера

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

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

Встраиваемый сервер под Windows

Библиотека встраиваемого сервера fbembed.dll, включенная в инсталлятор Firebird 1.5 для Windows, имеет архитектуру, аналогичную Firebird SuperServer. Если вы планируете инсталлировать и использовать fbembed.dll, обратите внимание на специальные инструкции по размещению библиотек и исполняемых программ Firebird. Измененные файлы README и другие заметки обычно размещаются в каталоге /doc серверной инсталляции.

Вы можете инсталлировать встраиваемый сервер и выполнять приложения встраиваемого сервера на машине Windows, на которой также находится Суперсервер или Классический сервер Firebird, хотя удаленные клиенты не могут соединяться с базой данных, с которой работает приложение встраиваемого сервера. В релизе 1.5, где не лучший протокол IPSERVER все еще используется для связи клиента и сервера, возможно использование библиотеки встраиваемого сервера в качестве клиента других серверов. В более поздних версиях, где протокол IPSERRVER заменен на XNET, это невозможно.

Firebird 1.0.x не содержит варианта встраиваемого сервера для Windows.

Встраиваемый сервер под Linux/UNIX

Встраиваемый сервер является «родным» режимом доступа локального клиента к Классическому серверу Firebird в Linux/UNIX, включая и версию Firebird 1.0.x. Библиотека встраиваемого сервера для локального доступа- libfbembed.so для Firebird 1.5 и выше и libgds.so для Firebird 1.0.x.

Как и версия IPSERVER для Windows, встроенный клиент в Linux/UNIX может так же работать, как удаленный клиент с другим Классическим сервером Firebird. При этом клиент не будет потокобезопасным (thread-safe). Для многопоточных приложений необходимо использовать обычный клиент libfbclient.so. В Firebird 1.0.x удаленный клиент поставляется в комплекте Суперсервер для Linux и двусмысленно назван libgds.so, как и встроенный клиент Классического сервера.

! ! !

ВНИМАНИЕ! Клиент Суперсервера для Linux является клиентом, поддерживающим потоки для многопоточных приложений, однако он не поддерживает выполнения нескольких потоков в одном и том же соединении с базой данных. Отдельные экземпляры соединения должны быть созданы для каждого потока.

. ! .

Сервисы API

Открытый код InterBase 6 — на основе которого был разработан Firebird — обрабатывает в первую очередь обращения к функциям интерфейса API для некоторых действий сервера, таких как копирование/восстановление, получение статистических данных и управление пользователями. Многие из этих обращений предоставляют программный интерфейс для инструментов командной строки. Небольшое количество функций сервера низкого уровня включает также некоторые функции, перекрывающие функции ядра API.

Некоторые организации разработали и распространяют сервисные компоненты, инкапсулирующие вызовы функций сервисов API из среды разработки Delphi, Kylix и C++ Builder. Большинство из них доступны для свободной загрузки с сайтов авторов или сообщества Firebird. Более подробную информацию см. в приложении 3.

В Firebird 1.0.x сервисы API и сервисные компоненты работают только с серверами типа Суперсервер. В Firebird 1.5 Classic сервисы API полностью поддерживаются только начиная с версии 1.5.2. В версиях 1.5.0 и 1.5.1 Classic поддерживаются только некоторые функции — такие как вызов модулей gbak (копирование/восстановление) и gfix (обслуживание базы данных).

Инсталляция клиентов

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

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

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

* В Firebird 1.0.x клиентские библиотеки используют те же имена и размещение, что и его двойник InterBase. Хотя возможно так установить приложения, чтобы они использовали переименованную клиентскую библиотеку, тем не менее, строго рекомендуется исключить размещение приложений Firebird 1.0.x и InterBase на одной и той же рабочей станции, если вы не уверены, что ваши приложения сконфигурированы так, чтобы отыскивать и использовать правильную библиотеку.

* Firebird 1.5 и более поздние версии под Windows может сосуществовать с InterBase и Firebird 1,0.x на сервере и клиенте. В Firebird 1.5 все еще имеют значение ручные установки, хотя с меньшими неприятностями, чем в версии 1.0.x. В версиях более поздних, чем 1.5, множество серверов и версий могут быть автоматически инсталлированы в Windows.

Инсталляция клиента Linux/UNIX

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

1. Подключитесь к клиентской машине как пользователь root и найдите клиентскую библиотеку в инсталляции сервера:

• в Firebird 1,0.x ее имя libgds.so.0, размещение по умолчанию /usr/lib;

• в Firebird 1.5 двоичные файлы удаленного клиента libfbclient.so. 1.5.0 инсталлированы по умолчанию в /opt/firebird/lib.

! ! !

ВНИМАНИЕ! В поставке Классического сервера есть клиентская библиотека с именем libfbembed.so.1.5, которая может быть использована для встроенных приложений. Не используйте ее для удаленных клиентов.

. ! .

2. Скопируйте библиотеку в /usr/lib на клиенте и создайте символическую ссылку на нее, используя следующие команды:

• для версии 1.0x:

ln -s /usr/lib/libgds.so.0 /usr/lib/libgds.so

• для версии 1.5 (две ссылки):

In -s /usr/lib/libfbclient.so.1.5 /usr/lib/libfbclient.so.0 In -s /usr/lib/libfbclient.so.0 /usr/lib/libfbclient.so

3. Создайте каталог/opt/firebird (/opt/interbase для версии 1.0.x) на клиенте для файла сообщений и скопируйте этот файл из корневого каталога Firebird на сервере:

• для версии 1,0.x скопируйте interbase.msg в /opt/interbase/;

• для версии 1.5 и выше скопируйте firebird.msg в /opt/firebird/.

4. В системном профайле оболочки по умолчанию или вызовом setenvo создайте переменную окружения, которая позволит найти утилиту для сообщений API:

• для версии 1.0.x создайте переменную INTERBASE и свяжите ее с /opt/interbase/;

• для версии 1.5 и выше создайте переменную FIREBIRD и свяжите ее с /opt/firebird/.

Инсталляция клиента Windows

Firebird 1.0.x

В Windows клиентская библиотека всегда по умолчанию инсталлировалась в системный каталог. По умолчанию это C:WINNTsystem32 для Windows NT и 2000, C:Windowssystem32 для Windows XP и Server 2000 и C:Windows или C:Windowssystem^[12] для Windows 9х и ME. В Firebird 1.0.x в качестве временной меры сохраняются старые имена и местоположение.

Использование инсталлятора Firebird

Самый простой способ инсталлировать клиента Firebird 1.0.x- это скопировать инсталлятор Firebird на компакт-диск или флэш-память и запустить его на клиентской машине, выбрав установку только клиента в диалоговом окне инсталлятора. Вы можете инсталлировать клиента с инструментами командной строки или без них. Большинству клиентов не нужны эти инструменты; не рекомендуется устанавливать их на клиентских рабочих станциях, где не требуется доступ администратора к серверу.

Инсталлятор создаст корневой каталог по умолчанию в C:Program FilesFirebird; это размещение вы можете изменить в соответствующем диалоге инсталлятора. Сюда он запишет файл сообщений interbase.msg и, если были выбраны для инсталляции инструменты командной строки, создаст каталог bin, куда поместит эти инструменты.

Он запишет в системный каталог gds32.dll и, если библиотека времени выполнения Microsoft С старая или вовсе отсутствует, запишет туда же msvcrt.dll.

Под конец он запустит программу instreg.exe для инсталляции ключей в системном реестре. Если вы выбрали каталог инсталляции по умолчанию, ключ будет

HKLMSoftwareBorlandInterBase. Если какие-нибудь выполняющиеся программы были перезаписаны в процессе инсталляции, вам будет предложено перезагрузить машину.

Инсталляция клиента вручную

Инсталляция клиента вручную требует выполнения всех предыдущих шагов. Вам нужно скопировать файлы gds32.dll, interbase.msg и instreg.exe на дискету или флэш- память. Также скопируйте из системного каталога msvcrt.dll, если на ваших клиентах она не установлена.

Создав корневой каталог Firebird, скопируйте туда interbase.msg. Затем запустите с диска instreg.exe, набрав в окне командной строки:

А:> instreg.exe ‘C:Program FilesFirebird’

Если вы создали корневой каталог Firebird где-нибудь в другом месте, укажите этот путь как аргумент корневого каталога.

Скопируйте gds32.dll и, если нужно msvcrt.dll, в системный каталог.

! ! !

ПРИМЕЧАНИЕ, msvcrt.dll является библиотекой времени выполнения для многих программ, скомпилированных компилятором Windows С. gds32.dll — это имя клиентской библиотеки для серверов InterBase, а также Firebird 1.0.x. В случае если вы не можете скопировать одну из библиотек или обе по причине их использования другой программой, необходимо остановить ту программу и повторить процесс копирования. Если все еще невозможно переписать библиотеки по причине того, что аварийно завершившаяся программа не выгрузила их, перезагрузите компьютер в безопасном режиме и выполните этот шаг.

. ! .

Firebird 1.5 и выше

Firebird версии 1.5 и последующие клиентские инсталляции поставляются с большим количеством режимов с целью избежать «ужаса DLL» в системном каталоге Windows.

До тех пор, пока сторонние инструменты, драйверы и компоненты не научатся понимать изменения в клиентской части Firebird 1.5, Firebird 1.5 будет поддерживать собственные «ужасы DLL». Инсталляция клиента по умолчанию почти наверняка будет несовместимой с программным обеспечением, созданным с использованием таких RAD-продуктов Borland, как Delphi или C++ Builder.

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

Использование инсталлятора Firebird

Хотя существуют другие варианты, рекомендуемый способ инсталляции клиента — использование инсталляционной программы Firebird 1.5.

Если вы используете инсталлятор, то первый выбор, который вы должны сделать — размещение корневого каталога для инсталляции клиента (рис. 7.1). Рекомендуется выбрать значение по умолчанию (C:Program FilesFirebirdFirebird_1_5), тогда будет проще в будущем выполнять обновления. Тем не менее при необходимости вы можете указать размещение на свой вкус.

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

Рис. 7.1. Выбор размещения корневого каталога инсталляции

Затем вы должны принять решение о выборе режима инсталляции — нужно ли устанавливать клиента с инструментами командной строки или без них, как показано на рис. 7.2.

Большинству клиентов эти инструменты не нужны; не рекомендуется инсталлировать их на клиентской рабочей станции, если нет необходимости администратору получать доступ к серверу. Для минимальной инсталляции выберите вариант Minimum client install — no server, no tools (Минимальная установка клиента — без сервера, без инструментов) и щелкните по кнопке Next.

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

Предыдущие инсталляторы устанавливали старую клиентскую библиотеку gds32.dll в системный каталог вместе с библиотекой времени выполнения для языка С msvcrt.dll, если она отсутствовала.

Рис. 7.2. Выбор инсталляции только клиента

Рис. 7.3. Выбор «версии» и размещения для клиента

В версии 1.5 инсталлятор устанавливает все DLL — новую клиентскую библиотеку fbclient.dll и (если требуется) библиотеку времени выполнения для С и C++ msvcp60.dll — в каталог bin в корневом каталоге Firebird.

* (A) Reallocation of the client library (Изменение размещения клиентской библиотеки). Если вам нужна совместимость с программным обеспечением, которое ожидает найти клиентскую библиотеку в системном каталоге, отметьте эту позицию.

* (В) Name of the client library (Имя клиентской библиотеки). Если вашему программному обеспечению или компонентам нужна клиентская библиотека с именем gds32.dll, отметьте эту позицию. Инсталлятор сгенерирует специальную копию fbclient.dll с именем gds32.dll и установит строку внутренней версии для совместимости с драйверами InterBase фирмы Borland и компонентами. Размещение этого файла зависит от состояния первой позиции (А).

Щелкните по кнопке Next для инсталляции.

Инсталляция клиента вручную

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

* %system%gds32.dll (C:WINNTsystem32 или C:Windows)

* firebird.msg

* binfbclient.dll

* binmsvcrt.dll (при необходимости)

* binmsvcp60.dll (при необходимости)

* bininstreg.exe

* bininstclient.exe

* binfbclient.local

* binmsvcrt. local

* binmsvcp60. local

На клиенте выполните следующие шаги:

1. Создайте корневой каталог Firebird и скопируйте туда firebird.msg.

2. В этом каталоге создайте каталог bin.

3. Скопируйте файлы из каталога bin дискеты в этот новый каталог bin.

4. Запустите программу instreg.exe из нового каталога bin в окне командной строки. Очень важно запустить эту программу из каталога bin корневого каталога Firebird, где расположена программа instreg.exe. Например, если корневой каталог Firebird находится в C:Firebird_Client, введите:

С:Firebird_Clientbin> instreg.exe install

5. Если у вас есть приложение, которому нужна клиентская библиотека с именем gds32.dll, то вам необходимо выполнить программу instclient.exe. Инструкции в следующем разделе.

Выполнение instclient.exe

Программа instclient.exe может быть выполнена, когда вам требуется клиентская версия, к которой осуществляют доступ существующие программы, драйверы или компоненты, которые ожидают, что имя клиентской библиотеки gds32.dll, или что она располагается по системному пути Windows. Это программа командной строки, которая находится в каталоге bin в корневом каталоге вашей инсталляции сервера

Firebird. При необходимости скопируйте данный файл в соответствующий каталог на клиентскую машину.

Инсталляция клиента в системный каталог

Откройте окно командной строки и перейдите в каталог bin. Синтаксис инсталляции клиента:

instclient.exe {i[nstall]} [-f[orce]] {fbclient | gds32}

Требуются параметры i (или install) и один из параметров fbclient или gds32.

Если программа найдет, что файл, который вы пытаетесь инсталлировать (fbclient.dll или gds32.dll), уже находится в системном каталоге, она не будет выполняться. Чтобы программа записывала файл, даже если найдет его копию, используйте переключатель -f (или -force).

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

! ! !

ВНИМАНИЕ! Если вы выбираете форсированную инсталляцию, вы рискуете разрушить клиента, который был инсталлирован для использования с другим программным обеспечением, которое было создано для соединения с сервером Firebird 1.0 или InterBase.

. ! .

Запрос к инсталлированному клиенту

Программа instclient.exe может быть использована для получения информации о выполняющихся на этой машине клиентах Firebird 1.5. Синтаксис запроса о клиентах:

instclient.exe {q[uery] fbclient | gds32}

На рис. 7.4 показана возвращаемая информация.

Рис. 7.4. Запрос с помощью instclient.exe

Использование instclient.exe для деинсталляции клиента версии 1.5

Для удаления клиента Firebird 1.5, инсталлированного в системный каталог, используйте следующий синтаксис:

instclient.exe {r[emove] fbclient | gds32}

Список имен и размещение клиентской библиотеки

В табл. 7.1 представлены имена клиентской библиотеки и размещение по умолчанию на клиентах Firebird.

Таблица 7.1. Имена и размещение по умолчанию клиентов Firebird

Версия, вид	ОС клиента	Библиотека	Размещение по умолчанию	Подключается к
Firebird 1,0.x Классический сервер	Linux/UNIX	libgds.so.0, символьная ссылка на libgds.so	/usr/lib	Только Классический сервер 1.0
Firebird 1.0 Суперсервер для Windows	Windows NT/2000	gds32.dll	C:WINNT system32	Любой сервер 1.0
-//-	Windows XP/Server 2003	gds32.dll	C:Windows system32	То же
-//-	Windows 9x/ME	gds32.dll	C:Windows	То же
Firebird 1.0 Суперсервер для Linux	Linux/UNIX	libgds.so.0, символьная ссылка на libgds.so. Обратите внимание, что эта библиотека отличается от клиента libgds.so в Классическом сервере	/usr/lib	Любой сервер 1.0 за исключением Классического сервера
Firebird 1.5 Классический сервер для Linux	Linux/UNIX	libfbembed.so.O или libfbclient.so.0, символьная ссылка на libfbembed.so или libfbclient.so, соответственно^[13]	/usr/lib	Только Классический сервер для Linux, приложения без потоков, возможны локальные соединения
Firebird 1.5 Суперсервер для Linux	Linux/UNIX	libfbclient.so.0, символьная ссылка на libfbclient.so	/usr/lib	Любой сервер 1.5
Firebird 1.5 Классический сервер и Суперсервер для Windows	Windows NT/2000	Родной: fbclient.dll	Firebird rootbin	Любой сервер 1.5
		Совместимость: fbclient.dll или gds32.dll, встроенный в instclient.exe	C:WINNT system32	То же
	Windows XP/Server 2003	Родной: fbclient.dll Совместимость: fbclient.dll или gds32.dll, встроенный в instclient.exe	C:Windows system32	Любой сервер 1.5
	Windows 9x/ME	Родной: fbclient.dll	Firebird rootbin	То же
		Совместимость: fbclient.dll или gds32.dll, встроенный в instclient.exe	C:Windows или C:Windowssystem^[14]	То же
Firebird 1.5 Встроенный сервер	Все встроенные клиенты Windows	fbembed.dll	Корневой каталог исполняемого модуля приложения	То же

Пора дальше

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

ЧАСТЬ III. Типы данных Firebird и домены

ГЛАВА 8. О типах данных Firebird.

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

Firebird поддерживает большую часть типов данных SQL. В дополнение он поддерживает динамически изменяемые типизированные и не типизированные большие двоичные объекты (Binary Large Object, BLOB) и многомерные однородные массивы для большинства типов данных.

Где задаются типы данных

Тип данных определяется для элементов данных в следующих ситуациях:

* при определении столбца в операторе CREATE TABLE;

* при создании шаблона глобально используемого столбца посредством CREATE DOMAIN;

* при изменении шаблона глобально используемого столбца с применением ALTER DOMAIN;

* при добавлении нового столбца в таблицу или при изменении столбца с использованием ALTER TABLE;

* при объявлении аргументов и локальных переменных в хранимых процедурах и триггерах;

* при объявлении аргументов и возвращаемых значений внешних функций (функций, определенных пользователем, UDF).

Поддерживаемые типы данных

Числовые типы данных (обсуждаемые в главе 9) следующие:

* BIGINT, INTEGER и SMALLINT;

* NUMERIC и DECIMAL;

* FLOAT и DOUBLE PRECISION.

Типы данных даты и времени (обсуждаемые в главе 10):

* DATE;

* TIME и TIMESTAMP.

Символьные типы данных (обсуждаемые далее в главе 11):

* CHARACTER;

* VARYING CHARACTER и NATIONAL CHARACTER.

Типы данных BLOB и массивы (обсуждаемые далее в главе 12):

* BLOB, типизированный и нетипизированный.

* ARRAY (массив).

Булевы типы данных

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

Советы по определению булевых доменов см. в главе 13.

«Диалекты» SQL

Firebird поддерживает три «диалекта» SQL, которые не имеют другого практического назначения, кроме конвертирования баз данных из InterBase версий 5.x в Firebird. «Родной» диалект Firebird в настоящий момент известен как диалект 3. По умолчанию Firebird создает новую базу данных в этом родном диалекте. Если в вашем опыте в Firebird нет ни груза существующих предположений, ни созданных баз данных, которые вам нужно обновить для Firebird, вы можете без риска «следовать естеству» и игнорировать все последующие замечания и предупреждения относительно диалекта 1.

Если вы бывший пользователь InterBase или применяли устаревшие инструменты для преобразования данных из других СУБД в InterBase, то диалекты SQL будут для вас предметом обсуждения в нескольких отношениях.

Поскольку вы можете работать с этой книгой в том порядке, который вам подходит, то вопросы влияния диалекта SQL будут отмечены соответствующим образом. Некоторые из наиболее серьезных эффектов разных диалектов проявляются в различии между типами данных. Вопросам диалектов посвящен разд. «Специальная тема миграции: диалекты SQL» этой главы.

Идентификаторы с разделителями в SQL-92

В базах данных диалекта 3 Firebird поддерживает соглашение ANSI SQL о необязательных идентификаторах с разделителями. Для использования зарезервированных слов, строк, чувствительных к регистру, или пробелов в именах объектов заключите имя в двойные кавычки. Это имя становится идентификатором с разделителями. К идентификаторам с разделителями всегда нужно обращаться, заключив их в кавычки.

Подробности см. в разд. «Соглашения и ограничения в именовании объектов базы данных» главы 14. Более подробную информацию об именовании объектов базы данных с использованием операторов CREATE и DECLARE см. в части IV этой книги. В приложении 11 представлен список ключевых слов, которые являются зарезервированными словами в SQL.

Контекстные переменные

Firebird делает доступным множество значений переменных, поддерживаемых системой в контексте текущего соединения клиента и его деятельности. Эти контекстные переменные доступны для использования в SQL, включая язык триггеров и хранимых процедур, PSQL. Некоторые доступны только в PSQL, большинство — только в диалекте 3 базы данных. В табл. 8.1 представлены контекстные переменные Firebird.

Таблица 8.1. Список контекстных переменных

Контекстная переменная	Тип данных	Описание	Доступность
CURRENT_CONNECTION	INTEGER	Системный идентификатор соединения, при котором выполняется настоящий запрос	Firebird 1.5 и выше, DSQL и PSQL
CURRENT_DATE	DATE	Текущая дата по часам на сервере	Firebird 1.0 и выше, все окружения SQL
CURRENT_ROLE	VARCHAR (31)	Имя роли, под которым соединился текущий пользователь. Возвращает пустую строку, если текущее соединение не использовало роль	Firebird 1.0 и выше, все окружения SQL
CURRENT_TIME	TIME	Текущее время по часам на сервере, выраженное в секундах после полуночи	Firebird 1.0 и выше, все окружения SQL
CURRENT_TIMESTAMP	TIMESTAMP	Текущая дата и время по часам на сервере в секундах	Firebird 1.0 и выше, все окружения SQL
CURRENT_TRANSACTION	INTEGER	Системный идентификатор транзакции, в контексте которой выполняется текущий запрос	Firebird 1.5 и выше, DSQL и PSQL
CURRENTUSER	VARCHAR( 128)	Имя пользователя, который связан сданным экземпляром клиентской библиотеки	Firebird 1.0 и выше, все окружения SQL
ROW_COONT	INTEGER	Счетчик строк измененных, удаленных и добавленных оператором DML после завершения операции	Firebird 1.5 и выше, DSQL и PSQL
UPDATING	BOOLEAN	Возвращает true, если выполняется оператор изменения	Firebird 1.5 и выше, только диалект триггера PSQL
INSERTING	BOOLEAN	Возвращает true, если выполняется оператор добавления	Firebird 1.5 и выше, только диалект триггера PSQL
DELETING	BOOLEAN	Возвращает true, если выполняется оператор удаления	Firebird 1.5 и выше, только диалект триггера PSQL
SQLCODE	INTEGER	Возвращает SQLCODE из блока исключения WHEN. Использование см. в главе 32	Firebird 1.5 и выше, только язык процедур PSQL
GDSCODE	INTEGER	Возвращает GDSCODE из блока исключения WHEN. Использование см. в главе 32	Firebird 1.5 и выше, только язык процедур PSQL
USER	VARCHAR(128)	Имя пользователя, который связан сданным экземпляром клиентской библиотеки	Предшественники InterBase, все версии Firebird, все окружения SQL, доступные в диалекте 1

Временные значения

CURRENT_CONNECTION и CURRENT_TRANSACTION не имеют смысла вне текущего соединения и контекста транзакции соответственно. Сервер Firebird сохранит самые последние значения этих идентификаторов в заголовочной странице базы данных. После восстановления базы данных из резервной копии эти значения будут заново установлены в ноль.

CURRENT_TIMESTAMP записывает время сервера на момент старта операции. Для всех записей, вставляемых или обновляемых одним оператором, значение этой переменной будет одним и тем же.

Хотя CURRENT_TIME хранится на сервере как время после полуночи, ее тип TIME, а не интервал времени. Для получения интервала времени используйте TIMESTAMP при старте и завершении и вычтите время старта из времени завершения. Результатом будет интервал времени в днях.

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

Примеры использования

Следующий оператор возвращает время сервера в момент, когда сервер обслуживает запрос клиента Firebird:

SELECT CURRENT_TIME AS TIME_FINISHED FROM RDB$DATABASE;

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

INSERT INTO TRANSACTIONLOG(TRANS_ID, USERNAME, DATESTAMP) VALUES (

CURRENT_TRANSACTION,

CURRENT_USER,

CURRENT_TIMESTAMP) ;

Предопределенные литералы даты

Литералы даты — заключенные в апострофы строки, которые Firebird SQL будет воспринимать как специальные даты. В диалекте 1 эти строки используются напрямую, в диалекте 3 они должны быть преобразованы в соответствующий тип. В табл. 8.2 показано использование дат в каждом диалекте.

Таблица 8.2. Список предопределенных литералов даты

Литерал даты	Подставляемая дата	Тип данных, Диалект 1	Тип данных, Диалект 3
‘NOW’	Текущая дата и время	DATE (эквивалентно TIMESTAMP в диалекте 3)	TIMESTAMP
‘TODAY’	Текущая дата	DATE с нулевым временем	DATE (только дата)
‘YESTERDAY’	Текущая дата -1	DATE c нулевым временем	DATE
‘TOMORROW’	Текущая дата + 1	DATE с нулевым временем	DATE

! ! !

ПРИМЕЧАНИЕ. В диалекте 1 тип данных DATE эквивалентен типу данных TIMESTAMP в диалекте 3. В диалекте 3 тип данных DATE содержит только дату. В диалекте 1 нет эквивалентного типа.

. ! .

Примеры использования предопределенных литералов даты

В диалектах базы данных 1 и 3 литерал даты должен быть преобразован в тип данных TIMESTAMP:

SELECT CAST (‘NOW’ AS TIMESTAMP) AS TIME_FINISHED FROM RDB$DATABASE;

Следующий оператор UPDATE устанавливает значение столбца даты в серверную дату плюс один день в диалекте 1:

UPDATE TABLE_A

SET UPDATE_DATE = ‘TOMORROW’

WHERE KEY_ID = 144;

Вот та же самая операция в диалекте 3 с преобразованием типа:

UPDATE TABLE_A

SET UPDATE_DATE = CAST(‘TOMORROW’ AS DATE)

WHERE KEY_ID = 144;

Столбцы

Данные в таких реляционных системах баз данных, как Firebird, логически упорядочены в виде множества строк и столбцов. Столбец хранит один элемент данных с атрибутами, идентичными для всех строк в наборе. Определение столбца имеет два обязательных атрибута: идентификатор (или имя столбца) и тип данных. Другие атрибуты могут быть включены в определение столбца, например, CHARACTER SET и ограничения типа NOT NULL и UNIQUE.

Множества, определенные для хранения данных, называются таблицами. Структура строк таблицы определяется при объявлении идентификатора таблицы; эта структура является списком идентификаторов столбцов, их типов данных и других необходимых атрибутов.

Простой пример объявления таблицы:

CREATE TABLE SIMPLE

( COLUMN1 INTEGER,

COLUMN2 CHAR(3),

COLUMN3 DATE);

Полное описание объявления таблиц и столбцов см. в главе 16.

Домены

В Firebird вы можете сделать предварительное объявление столбца с типом данных и «шаблонным набором» атрибутов в виде домена. Как только домен будет создан и подтвержден (commit), он может быть использован в любой таблице вашей базы данных, как если бы он был типом данных.

! ! !

ПРИМЕЧАНИЕ. Существуют некоторые ограничения по использованию доменов. В частности, домен не может применяться в объявлении локальных переменных, входных и выходных аргументов в модулях PSQL (язык процедур).

. ! .

Столбцы, основанные на домене, наследуют все атрибуты домена: его тип данных, другие атрибуты, включая значение по умолчанию, ограничения на значения, набор символов и порядок сортировки.

Любой атрибут за исключением типа данных может быть переопределен при использовании домена в определении столбца при определении таблицы путем замены атрибута на другой совместимый атрибут или при добавлении атрибута. Например, можно объявить домен с набором атрибутов, не включающих NOT NULL, для которого можно сделать допустимым пустое значение в одних случаях, a NOT NULL в других.

Более подробную информацию о создании, использовании и поддержке доменов см. в главе 13.

Преобразование типов данных

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

Неявное преобразование типов

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

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

* В диалекте 3 в условиях поиска требуется функция CAST() для явной трансляции одного типа данных в другой для операций сравнения.

Например, сравнение столбца типа DATE или TIMESTAMP с ’12/31/2003′ в диалекте 1 приводит к неявному преобразованию строкового литерала ’12/31/2003′ в тип данных DATE.

SELECT * FROM TABLE_A

WHERE START_DATE < ’12/31/2003′;

В диалекте 3 требуется явное преобразование:

SELECT * FROM TABLE_A

WHERE START_DATE < CAST (’12/31/2003′ AS DATE);

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

3 + ‘1’

диалект 1 автоматически преобразует символ «1» в SMALLINT, в то время как диалект 3 вернет ошибку. Он требует явного преобразования типов:

3 + CAST(‘1’ AS SMALLINT)

Оба диалекта вернут ошибку в следующем операторе, потому что Firebird не может преобразовать символ «а» в целое:

3 + ‘а’

Явное преобразование типов: CAST()

В тех случаях, когда Firebird не может выполнить неявное преобразование типов, вы должны выполнить явное преобразование типов посредством функции CAST(). Используйте CAST() для преобразования одного типа данных в другой в операторе SELECT обычно в предложении WHERE для сравнения различных типов данных. Синтаксис функции:

CAST (значение | NOLL AS тип данных)

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

Изменение определения столбцов и доменов

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

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

* Преобразование числового типа данных в строковый требует минимального размера строкового типа, как показано в табл. 8.3.

Таблица 8.3. Минимальное количество символов для числовых преобразований

Тип данных	Минимальная длина символьного типа
BIGINT	19 (или 20 для чисел со знаком)
DECIMAL	20
DOUBLE	22
FLOAT	13
INTEGER	10 (11 для чисел со знаком)
NUMERIC	20 (или 21 для чисел со знаком)
SMALLINT	6

Изменение типа данных столбца

Используйте предложение ALTER COLUMN В операторе ALTER TABLE, например:

ALTER TABLE table1 ALTER COLUMN field1 TYPE char(20);

Информацию об изменении столбцов таблицы см. в разд. «Изменение таблиц» главы 16.

Изменение типа данных домена

Используйте предложение TYPE В операторе ALTER DOMAIN для изменения типа данных домена, например,

ALTER DOMAIN MyDomain TYPE VARCHAR(40);

На рис. 8.1 показаны допустимые преобразования типов данных. Более подробную информацию об изменении атрибутов домена см. в главе 13.

Ключевые слова, используемые для спецификации типа данных

Ключевые слова для спецификации типов данных в операторах DDL представлены здесь в качестве краткой справки. Точный синтаксис см. в соответствующей главе, связанной с типами данных этой части книги, а также в главах 13 и 16.

{SMALLINT | INTEGER | FLOAT | DOUBLE PRECISION} [<array_dim>]

| {DATE | TIME | TIMESTAMP} [<array_dim>]

| {DECIMAL INUMERIC} [ (precision [, scale])] [<array_dim>]

{ {CHAR | CHARACTER | CHARACTER VARYING | VARCHAR} [(int)]

[<array_dim>] [CHARACTER SET charname]

| {NCHAR | NATIONAL CHARACTER | NATIONAL CHAR}

[VARYING] [(int)] [<array_diin>]

BLOB [SUB_TYPE int | subtype_name ] [SEGMENT SIZE int]

[CHARACTER SET charname]

BLOB [(seglen [, subtype])]

Рис. 8.1. Допустимые преобразования данных с использованием операторов ALTER COLUMN и ALTER DOMAIN

Специальная тема миграции: диалекты SQL

Если вы бывшие пользователи InterBase или вы использовали устаревшие инструменты миграции для конвертирования других СУБД в

InterBase, то диалекты SQL видимо будут влиять на некоторые аспекты новой жизни ваших баз данных и приложений при использовании сервера Firebird.

ODS и диалект

Структура данных на диске (On-Disk Structure, ODS) идентифицирует базу данных в отношении версии релиза сервера Firebird или InterBase, который создает и восстанавливает базу данных. ODS базы данных влияет на совместимость с версиями сер- вера. Файл, подходящий для обновления ODS, может быть создан резервным копированием базы данных (backup) с использованием утилиты gbak той версии, в которой была создана база данных. Утилита должна быть использована с переключателем -t[ransportable]. Когда файл резервной копии будет восстановлен с использованием gbak новой версии, восстановленная база данных будет иметь новую версию ODS. Такое невозможно выполнить для «понижения» ODS для любой базы данных.

Использование gbak подробно обсуждается в главе 38.

Обновление ODS не изменяет диалект

Обновление ODS не влияет на диалект SQL базы данных: база данных диалекта 1 останется базой данных диалекта 1.

Базы данных Firebird

Firebird 1.0.x имеет ODS, обозначаемый как ODS-10. Firebird 1.5 имеет ODS-10.1. Чтобы преобразовать базу данных ODS-10, созданную в Firebird 1.0.x в ODS-10.1, вам просто нужно сделать ее резервную копию и восстановить эту копию с использованием gbak из Firebird 1.5. По умолчанию серверы Firebird версий 1.0.3+ и 1.5 создают базы данных диалекта 3. Для проверки ваших баз данных см. разд. «Как определить диалект» далее в этой главе.

Базы данных InterBase 6.0.x

OpenSource InterBase версий 6.0.x имеют ODS-10. Тем не менее для обновления баз данных InterBase 6.0.x до любой версии Firebird рекомендуется использовать gbak из InterBase 6.0 с переключателем -t[ransportable]. Файл резервной копии должен быть затем восстановлен с использованием gbak соответствующей версии сервера Firebird.

Если база данных InterBase 6.0 была создана с установками по умолчанию, то, вероятно, она имеет диалект 1. См .разд. «Как определить диалект» далее в этой главе.

Базы данных InterBase 5.x

Базы данных InterBase 5 имеют ODS-9 (9.0 и 9.1). Серверы Firebird могут открывать их, читать как базы данных диалекта 1, но дальнейшая работа с этими базами данных в InterBase 5.x не рекомендуется.

! ! !

ПРИМЕЧАНИЕ. Сервер Firebird не может создавать базы данных с ODS-9. Базы данных диалекта 1, созданные сервером Firebird, не могут быть использованы сервером InterBase 5.x.

. ! .

Не существует такой вещи, как база данных ODS-9 диалекта 1 или диалекта 3. Для обновления базы данных ODS-9 до Firebird используйте программу gbak из InterBase 5.x, запущенную с сервера InterBase 5.6 с переключателем -t[ransportable]. Обновление базы данных InterBase 5.x до Firebird не преобразует ее в диалект 3 базы данных. Ее SQL диалект будет 1, и это обновление является необратимым.

Где учитывается диалект

Концепция диалекта различает способ поддержки типов данных и возможности языка, доступные в базах данных с ODS-9 (диалект 1) и ODS-10 и выше (диалект 3). Сам сервер не имеет «диалекта» — диалект базы данных сохраняется как атрибут базы данных. Он является интерфейсом клиента, который определяет, какой набор возможностей запрашивается у базы данных. При некоторых условиях, если вы как разработчик приложений или пользователь инструментов администратора используете его неправильно, вы получите ошибочные данные, сохраняемые в базе, что может привести к некорректной работе приложений и базы данных.

Здесь удобно обратиться к экземпляру клиентского соединения, выполненного с помощью библиотеки API или пользовательского драйвера языка, такого как JayBird (Java), ODBC или провайдер .NET, как «клиент диалекта 1» или «клиент диалекта 3». Это означает, что интерфейс клиента будет установлен для получения возможностей диалекта 1 или 3.

Что можно отбросить

Следующий список иллюстрирует некоторые отличия диалекта 1 от диалекта 3.

* Диалекты 1 и 3 хранят большие масштабируемые числа по-разному. В диалекте 3 все типы с фиксированной точкой (NUMERIC и DECIMAL), имеющие точность больше 10, являются 64-битовыми целыми с описанием, которое включает некоторые атрибуты для определения точности и масштаба. В диалекте 1 числа с фиксированной точкой хранятся как 16- или 32-битовые целые, а числа с точностью, превышающей 10, преобразуются для хранения в 64-битовый тип числа с плавающей точкой DOUBLE PRECISION. Ваши данные, вероятно, вызовут ошибку переполнения, если клиент диалекта 3 выдаст запрос на сохранение числа в базе данных диалекта 1, или сгенерируют ошибочный результат, когда клиент диалекта 1 выдаст запрос на операции с числами в базе данных диалекта 3.

* Генераторы в диалекте 3 являются 64-битовыми целыми, в то время как в диалекте 1 генераторы — 32-битовые целые.

* Арифметические операции в диалекте 3 были взяты из стандарта SQL-92, в то время как диалект 1 использует нестандартные правила. Например, деление целого на целое в диалекте 3 возвращает усеченное целое, в то время как в диалекте оно вернет число с плавающей точкой двойной точности. Если ваше приложение сохраняет результат выражения, включающего подобную арифметическую операцию, «ошибочные» результаты будут сохранены без возбуждения исключения.

* Оба диалекта имеют тип данных даты и времени с именем DATE, но это разные типы. В диалекте 1 тип DATE эквивалентен типу TIMESTAMP диалекта 3, а в диалекте 3 DATE является типом, хранящим только дату; этот тип не поддерживается в диалекте 1.

* Диалект 3 поддерживает тип TIME (время дня), который отсутствует в диалекте 1.

* В базах данных диалекта 3 Firebird поддерживает соглашения ANSI SQL по идентификаторам с разделителями, которые заключаются в двойные кавычки; такие

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

* Диалект 3 имеет больше зарезервированных ключевых слов, чем диалект 1. Существующие базы данных диалекта 1, которые используют новые ключевые слова в качестве идентификаторов, не будут работать с клиентом диалекта 3.

* Диалекты 1 и 3 ведут себя по-разному в случае неявного преобразования типов. Это может стать проблемой, если вы хотите конвертировать существующую базу данных в диалект 3 и изменять использующие ее приложения.

Диалект 2

Не существует такого предмета, как «база данных диалекта 2». Диалект 2 является клиентской установкой, которую вы можете использовать для проверки переходных требований типов данных при конвертировании базы данных диалекта 1 в диалект 3. Inprise Corporation (теперь Borland) разработала документ «Migration Guide» (Руководство по миграции) для InterBase 6.0 в 2000 году, где подробно описаны действия по конвертированию баз данных диалекта 1 в диалект 3. Этот документ в формате PDF доступен на некоторых сайтах сообщества Firebird.

Как определять диалект

Вызовите окно командной строки и перейдите в каталог /bin, где находятся инструменты командной строки Firebird. Запустите утилиту isql. Соединитесь с вашей базой данных:

SQL> CONNECT ‘/opt/firebird/examples/employee.fdb’

CON> user ‘SYSDBA’ password ‘icur2yy4m’;

SQL>

Затем введите следующую команду ISQL:

SQL> SHOW SQL DIALECT;

Client SQL dialect is set to: 3 and database dialect is: 3

(Диалект SQL клиента установлен в: 3, диалект базы данных: 3)

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

Изменение диалекта клиента в isql

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

SQL> COMMIT;

SQL> SET SQL DIALECT 1;

WARNING: client SQL dialect has been set to 1 when connecting to Database

SQL dialect 3 database.

(Предупреждение: SQL-диалект клиента установлен в 1 при соединении с базой данных с SQL-диалектом 3)

SQL>

Здесь все в порядке, потому что вы только собираетесь соединиться с базой данных диалекта 1:

SQL> CONNECT ‘RSERVER:D:DATASAMPLElegacy.gdb’

CON> user ‘SYSDBA’ password ‘icur2yy4m’;

SQL> SHOW SQL DIALECT;

Client SQL dialect is set to: 1 and database dialect is: 1

(Диалект SQL клиента установлен в: 1, диалект базы данных: 1)

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

Пора дальше

Следующие четыре главы подробно описывают типы данных, поддерживаемые для каждой из основных категорий данных: числа, дата/время, символы и BLOB. Глава 13, последняя глава в этой части, описывает реализацию доменов в Firebird для объединения типа данных с группой атрибутов в одно воспроизводимое определение.

ГЛАВА 9. Числовые типы данных.

Firebird поддерживает числовые типы данных с фиксированной точкой (точные числа) и с плавающей точкой (приблизительная точность). Десятичными типами с фиксированной точкой являются целые типы с нулевым масштабом SMALLINT, INTEGER и в диалекте 3 BIGINT, а также два почти одинаковых масштабируемых числовых типа: NUMERIC и DECIMAL. Два типа с плавающей точкой: FLOAT (низкая точность) и DOUBLE PRECISION^[15].

Firebird не поддерживает беззнаковый целочисленный тип. В табл. 9.1 показаны диапазоны значений каждого числового типа в Firebird.

Таблица 9.1. Границы числовых типов Firebird

Числовой тип	Минимум	Максимум
SMALLINT	-32,768	32,767
INTEGER	-2,147,483,648	2,147,483,647
BIGINT	-2(^63^)	2(^63^) — 1
(Для мазохистов)	-9223372036854775808	9223372036854775807
NUMERIC*	Меняется	Меняется
DECIMAL*	Меняется	Меняется
FLOAT
Положительные	1.175 * 10(^38^)	3.402 * 10(^38^)
Отрицательные	-3.402 * 10(^38^)
DOUBLE PRECISION
Положительные	2.225 * 10(^308^)	1.797 * 10(^308^)
Отрицательные	-1.797 * 10(^308^)

* Границы для типов NUMERIC и DECIMAL изменяются в зависимости от способа хранения и масштаба. Границы всегда будут соответствовать тому типу, в котором эти данные будут сохраняться^[16].

Операции с числовыми типами

* Операции сравнения. Используйте стандартные операторы отношений (=, <, >, >=, <=, <> или !=)^[17].

Возможны сравнения строк с использованием таких операторов SQL, как CONTAINING, STARTING WITH и LIKE. В данных операциях числа трактуются как строки. Более подробную информацию об этих операторах см. в главе 21.

* Арифметические операции. Могут быть использованы стандартные бинарные арифметические операторы (+, * и /).

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

* Операции сортировки. По умолчанию запрос возвращает строки точно в том порядке, в котором находит их в таблице, т. е., скорее всего, неупорядоченные. Вы можете отсортировать строки по значениям целочисленных столбцов, используя предложение ORDER BY оператора SELECT В убывающем или возрастающем порядке. Если числа сохраняются как символьные типы, то порядок сортировки будет алфавитно-цифровым, а не числовым, например, 1 — 10 — 11 … 19 — 2.

Целые типы

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

* SMALLINT — является знаковым коротким целым с диапазоном от -32,768 до 32,767;

* INTEGER — является знаковым длинным целым с диапазоном от-2 147 483 648 до 2 147 483 647;

* BIGINT — является знаковым 64-битовым целым с диапазоном от 2(^63^) до 2(^63^) — 1. Недоступен в диалекте 1.

! ! !

ПРИМЕЧАНИЕ. В Firebird 1.0.x в диалекте 3 объявляйте 64-битовые целые как NUMERIC(18,0) или DECIMAL (18,0). Всегда допустимо использование этого синтаксиса для целых типов, при этом можно опускать второй аргумент (масштаб).

. ! .

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

Следующие два оператора создают домен и столбец, соответственно, с типами данных SMALLINT и INTEGER:

CREATE DOMAIN RGB_RED_VALUE AS SMALLINT;

/* */

CREATE TABLE STUDENT_ROLL (

STUDENT_ID INTEGER,

. . . );

Каждый из следующих операторов создает домен, который является 64-битовым целым:

CREATE DOMAIN IDENTITY BIGINT CHECK(VALUE >=0);

/* Firebird 1.5 и выше */

CREATE DOMAIN IDENTITY NUMERIC(18,0) CHECK(VALUE >=0);

SMALLINT

SMALLINT является 2-байтовым целым, предоставляющим компактное хранение для целых чисел с ограниченным диапазоном значений. Например, SMALLINT может быть подходящим для хранения значений цветов в форме RGB, как показано в предыдущем примере создания домена.

SMALLINT часто используется для определения булевых значений, обычно 0 = ложь, 1 = истина. Пример такого использования можно найти в разд. «Объявление булевых доменов» главы 13.

INTEGER

INTEGER является 4-байтовым целым. В диалекте 1 генераторы (см. разд. «Генераторы» этой главы) генерируют значения типа INTEGER. Вы можете хранить такие целые в столбцах BIGINT без преобразования.

BIGINT, NUMERIC(18,0)

Доступны только в диалекте 3. Это 8-байтовое целое, полезное для хранения целых чисел с очень маленькими и очень большими значениями. В диалекте 3 генерируются числа типа BIGINT (см. разд. «Генераторы»).

Автоинкремент или тип IDENTITY

Firebird не поддерживает типы автоинкремента или IDENTITY, которые вы могли встретить в других системах управления базами данных. Что у него есть, так это средство числовых генераторов и возможность поддерживать независимые, именованные серии чисел BIGINT. Каждая серия известна как генератор. Техника их использования для реализации и поддержки первичных ключей и других автоматических инкрементных серий описана в главе 31.

Генераторы

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

CREATE GENERATOR AGenerator;

Генераторам может быть присвоено любое начальное значение:

SET GENERATOR AGenerator ТО 1;

! ! !

ВНИМАНИЕ! Существуют строгие предупреждения по поводу переустановки значений генераторов, когда эти значения находятся в использовании — см. разд. «Предупреждения о переустановке значений генераторов» в этой главе.

. ! .

Получение следующего значения

Для получения следующего значения вызывайте функцию SQL GEN_ID(ИмяГенератора, n), где имягенератора — имя генератора, а n — целое (диалект 1) или NUMERIC(18,0) (диалект 3), определяющее значение шага. Запрос:

SELECT GEN_ID(AGenerator, 2) from RDB$DATABASE;

возвращает число, которое на 2 больше последнего сгенерированного числа, и устанавливает значение генератора в сгенерированное значение.

Текущее значение генератора

Следующая строка:

SELECT GEN_ID(AGenerator, 0) from RDB$DATABASE;

возвращает текущее значение генератора без его увеличения^[18].

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

. . .

DECLARE VARIABLE MyVar BIGINT;

. . .

MyVar = GEN_ID(AGenerator, 1);

Более подробную информацию об использовании генераторов в модулях PSQL — в особенности в триггерах — см. в главе 29^[19].

Использование отрицательного шага

Аргумент шаг в GEN_ID может быть отрицательным. Следовательно, можно устанавливать или переустанавливать текущее значение генератора, передавая отрицательный аргумент или в виде целой константы, или в виде целого выражения. Эта возможность иногда используется как «трюк» для установки значений генератора в PSQL, поскольку в PSQL не могут использоваться такие команды DDL, как SET GENERATOR.

Например, оператор:

SELECT GEN_ID (AGenerator, -GEN_ID (AGenerator, 0)) from RDB$DATABASE;

устанавливает значение генератора в ноль.

Предупреждения о переустановке значений генераторов

Основное простое правило по переустановке значений генераторов в работающей базе данных — будь то в SQL, PSQL или в некотором интерфейсе администратора — не делать этого.

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

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

Никогда не переустанавливайте значения генератора в попытке скорректировать программные ошибки, ошибки ввода данных или для «устранения промежутков» в последовательности значений^[20].

Масштабируемые типы с фиксированной точкой

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

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

Например, следующий оператор использует ставку налога (DECIMAL(5,4)) и чистую прибыль (NUMERIC (18, 2)):

UPDATE ATABLE

SET INCOME_AFTER_TAX = NET_PROFIT — (NET_PROFIT * TAX_RATE) ;

Пусть ставка налога будет 0.3333.

Пусть чистая прибыль будет 1234567890123456.78.

Результат:

ISC ERROR CODE:335544779

Integer overflow. The result of an integer operation caused the most significant bit of the result to carry.

(Переполнение целого числа. Результат целочисленной операции привел к переносу большинства значащих битов)

Firebird предоставляет два типа данных чисел с фиксированной точкой или масштабируемых: NUMERIC и DECIMAL. Каждый масштабируемый тип объявляется как TYPE(p, s), где p определяет точность (количество значащих цифр), а s — масштаб (размещение десятичной точки — т. е. количество цифр справа от символа десятичной точки).

В соответствии со стандартом SQL-92 оба типа NUMERIC и DECIMAL ограничивают хранимое число объявленным масштабом. Различие между этими двумя типами заключается в способе, каким ограничивается точность. Точность должна быть такой, «как объявлено» для столбцов типа NUMERIC, в то время как столбцы DECIMAL могут получать числа, чья точность по меньшей мере равна тому, что было объявлено, больше границы реализации.

Типы NUMERIC и DECIMAL, как они реализованы в Firebird, являются идентичными, за исключение случая, когда точность меньше пяти. Оба типа действительно соответствуют стандарту типа DECIMAL, NUMERIC не соответствует SQL-92.

Внутренне Firebird хранит масштабированное число как типы SMALLINT(16 бит), INTEGER (32 бита) или BIGINT(64 бита) в соответствии с объявленным размером точности. Его объявленная точность^[21] сохраняется вместе с объявленным масштабом в виде отрицательного множителя масштаба^[22], представляющего степень числа 10. Когда к числу происходит обращение для вывода или для расчетов, оно получается произведением хранимого целого на 10 в степени «множитель масштаба» ( 10(^множитель масштаба^) )

Например, для столбца, объявленного как NUMERIC(4,3), Firebird сохраняет внутренне число в виде SMALLINT. Если вы вводите число 7.2345, Firebird без сообщений округляет самую правую цифру (4) и сохраняет 16-битовое целое 7235 и множитель масштаба -3. Это число будет найдено как 7.235 (7235 * 10(^-3^)).

Тип данных NUMERIC

Формат типа данных NUMERIC:

NUMERIC(p,s)

Например, NUMERIC (4,2) определяет число, состоящее не более чем из четырех цифр, включая две цифры справа от десятичной точки. Следовательно, числа 89.12 и 4.321 будут сохранены в столбце NUMERIC(4,2) как 89.12 и 4.32 соответственно. Во втором примере последняя цифра 10(^-3^) выходит за пределы масштаба и просто отбрасывается.

И все же возможно хранение в этом столбце числа с большей точностью, чем было объявлено. Максимально здесь может быть 327.67 — т. е. число с точностью 5. Поскольку база данных хранит фактическое число как SMALLINT, числа не начинают вызывать ошибки переполнения, пока внутренне хранимое число не станет больше 32,767 или меньше -32,768.

Тип данных DECIMAL

Формат типа данных DECIMAL:

DECIMAL(Р, S)

Как и в случае NUMERIC, DECIMAL(4,2) определяет число, состоящее, по меньшей мере, из четырех цифр, включая две цифры справа от десятичной точки. Тем не менее, поскольку Firebird сохраняет данные DECIMAL с точностью 4 и меньше как INTEGER, этот тип может в столбце DECIMAL(4,1) потенциально хранить число от 214 748 364 до -214 748 364.8 без появления ошибки переполнения.

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

Таблица 9.2. Диапазон и способ хранения в Firebird типов данных NUMERIC и DECIMAL

Точность	Тип	Диалект 1	Диалект 3
1-4	NUMERIC	SMALLINT	SMALLINT
1-4	DECIMAL	INTEGER	INTEGER
5-9	NUMERIC и DECIMAL	INTEGER	INTEGER
10-18	NUMERIC и DECIMAL	BIGINT	DOUBLE PRECISION*

* Точные числа с точностью больше чем 9, могут быть объявлены в диалекте 1 базы данных без появления исключения. Эти числа будут храниться как DOUBLE PRECISION и будут подчиняться тем же самым ограничениям точности, что и любые числа с плавающей точкой. В процессе преобразования базы данных диалекта 1 в диалект 3 клиент диалекта 2, открыв таблицу, содержащую столбцы DECIMAL или NUMERIC с точностью, большей 9, получит сообщение об ошибке. Более подробную информацию о преобразованиях диалекта 1 в диалект 3 см. в разд. «Специальная тема миграции: диалекты SQL» главы 8.

Конвертированные базы данных

Если база данных диалекта 1 была обновлена до диалекта 3 с использованием создания резервной копии gbak, а затем восстановлена, то числовые поля, определенные с точностью, большей 9, сохранят тип данных DOUBLE PRECISION. Хотя они будут представлены так, как были вначале определены (например, NUMERIC (15,2)), они будут сохраняться и использоваться в вычислениях как DOUBLE PRECISION.

Более подробную информацию о преобразованиях баз данных диалекта 1 в диалект 3 см. в разд. «Специальная тема миграции: диалекты SQL» главы 8.

Специальные ограничения в статическом SQL

Включающий язык встроенных приложений не может использовать или распознавать малые точности типов данных NUMERIC или DECIMAL С дробной частью, когда они внутренне хранятся как типы SMALLINT или INTEGER. для устранения такой проблемы в любой базе данных, к которой предполагается доступ из таких встроенных приложений (ESQL):

* не определяйте столбцы или домены с типом NUMERIC или DECIMAL малой точности в базе данных диалекта 1. или храните данные как целые и пишите в приложениях код, учитывающий масштаб, или используйте DOUBLE PRECISION и применяйте подходящий алгоритм округления для вычислений;

* в базе данных диалекта 3 определяйте столбцы или домены любого размера типа NUMERIC и DECIMAL, используя точность не меньше 10, чтобы получить их внутреннее хранение как BIGINT. Указывайте масштаб, если вы хотите управлять точностью и масштабом. Используйте ограничения CHECK, если вам нужно контролировать диапазоны значений.

Поведение типов с фиксированной точкой в операциях

Деление

При выполнении деления типов с фиксированной точкой диалекты 1 и 3 ведут себя по-разному.

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

В диалекте 1 деление всегда создает частное типа DOUBLE PRECISION.

Примеры

В диалекте 3 частное от деления DECIMAL(12,3) на DECIMAL(9,2) будет DECIMAL(18,5). Масштабы суммируются:

SELECT 11223344.556/1234567.89 FROM RDB$DATABASE

Это дает 9.09090.

Посмотрим, чем отличается частное, когда этот же запрос выполняется в диалекте 1. Первый операнд трактуется как число DOUBLE PRECISION, потому что его точность (12) превышает максимум масштабируемого типа для диалекта 1. Частное также является числом DOUBLE PRECISION. Результат 9.09090917308727 по причине ошибок, присущих типам с плавающей точкой.

Для следующей таблицы, определенной в диалекте 3, операции деления дают различные результаты.

CREATE TABLE t1 (

i1 INTEGER,

i2 INTEGER,

n1 NUMERIC(16, 2),

n2 NUMERIC(16,2));

COMMIT;

INSERT INTO t1 VALUES (1, 3, 1.00, 3.00);

COMMIT;

Следующий запрос возвращает значение 0.33 типа NUMERIC(18,2), потому что сумма масштабов 0 (операнд 1) и 2 (операнд 2) равна 2:

SELECT i1/n2 from t1

Следующий запрос возвращает значение 0.3333 типа NUMERIC (18,4), потому что сумма масштабов двух операндов равна 4:

SELECT n1/n2 FROM t1

Деление целого на целое

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

SELECT i1/i2 FROM t1

В диалекте 1, как и в большинстве других СУБД, деление одного целого на другое целое даст результат с плавающей точкой типа DOUBLE PRECISION:

SELECT 1/3 AS RESULT FROM RDB$DATABASE

Это дает .333333333333333.

Хотя настоящее правило диалекта 1 является интуитивным для языков программирования, оно не соответствует стандарту SQL-92. Целые типы имеют масштаб 0. Для согласованности это требует, чтобы результат (частное) любой операции деления целого на целое соответствовал правилам масштабирования для чисел с фиксированной точкой и был бы целым.

Диалект 3 соответствует стандарту и усекает частное от операций деления целого на целое до целого. Следовательно, следующий оператор является неразумным:

SELECT 1/3 AS RESULT FROM RDB$DATABASE

Он вернет 0.

Если вам нужно сохранить дробную часть в результате (в частном) деления целого на целое в диалекте 3, убедитесь, что у одного из операндов присутствует нужный масштаб, или включите «множитель» в выражение, чтобы гарантировать масштаб результата.

Примеры:

SELECT 1.00/3 AS RESULT FROM RDB$DATABASE

Вернет .33.

SELECT (5 * 1.00)/2 AS RESULT FROM RDB$DATABASE

Этот вернет 2.50.

Диалект 1 базы данных с диалектом 3 клиента

База данных диалекта 1, которая была открыта клиентом диалекта 3, может преподнести некоторые сюрпризы в отношении деления целых чисел. Когда операция выполняет нечто, что приводит к проверке условия CHECK, или выполняется хранимая процедура или триггер, то осуществляемые действия основаны на диалекте, на котором CHECK, хранимая процедура или триггер были определены, а не на действующем диалекте, на котором приложение выполняет проверку, хранимую процедуру или триггер.

Например, в базе данных диалекта 1 таблица содержит столбцы MYCOL1 (INTEGER) и MYCOL2 (INTEGER) и следующее условие CHECK, которое было определено, когда база данных имела диалект 1:

CHECK(MYCOL1 / MYCOL2 >0.5)

Пусть теперь пользователь запускает isql или приложение, задав диалект 3. Программа пытается добавить строку в конвертированную базу данных:

INSERT INTO MYTABLE (COL1, COL2) VALUES (2,3);

Поскольку ограничение CHECK было определено в диалекте 1, оно вернет частное 0.666666666666667, и строка будет соответствовать условию CHECK.

Обратное также верно. Если то же ограничение CHECK было добавлено в базу данных диалекта 1 из клиента диалекта 3, то для ограничения будет сохранена арифметика диалекта 3. Предыдущий оператор INSERT не будет выполнен, потому что проверка вернет значение частного 0, которое нарушает это ограничение.

! ! !

СОВЕТ. Мораль всего этого: используйте базы данных диалекта 3 и всегда соединяйтесь с ними, применяя диалект 3. Если вы собираетесь использовать Firebird, то обновите все существующие базы данных до диалекта 3 — желательно описав новую базу данных и поместив в нее ваши старые данные — таким образом вы сохраните покой и сможете избежать уймы неприятных сюрпризов.

. ! .

Умножение и деление

Если оба операнда являются точными числами, умножение операндов даст точное число с масштабом, равным сумме масштабов операндов. Например,

CREATE TABLE t1 (

n1 NUMERIC(9,2),

n2 NUMERIC (9,3) ) ;

COMMIT;

INSERT INTO t1 VALUES (12.12, 123.123);

COMMIT;

Следующий запрос возвращает число 1492.25076, потому что n1 имеет масштаб 2, а n2 — масштаб 3. Сумма масштабов 5.

SELECT n1*n2 FROM t1

В диалекте 3 точность результата умножения чисел с фиксированной точкой будет равна 18. Нужно принять меры предосторожности, чтобы быть уверенным, что не будет переполнения результата при распространении масштаба в умножении.

В диалекте 1, если распространение масштаба приводит к тому, что вычисление даст результат с точностью больше 9, то результатом будет DOUBLE PRECISION.

Сложение и вычитание

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

CREATE TABLE t1 (

n1 NUMERIC(9, 2) ,

n2 NUMERIC(9, 3)) ;

COMMIT;

INSERT INTO t1 VALUES (12.12, 123.123);

COMMIT;

SELECT n1 + n2 FROM t1;

Этот запрос возвращает 135.243, выбирая максимальный масштаб операндов. Аналогично, следующий запрос возвращает число -111.003:

SELECT n1 — n2 FROM t1;

В диалекте 3 результат любого сложения или вычитания имеет тип NUMERIC(18,n). В диалекте 1 он имеет тип NUMERIC (9, n), где n — масштаб максимального операнда.

Числовой ввод и показатели степени

Любые числовые строки в DSQL, которые могут быть сохранены как DECIMAL(18,S), вычисляются без потери точности, что могло бы произойти при промежуточном сохранении в виде DOUBLE. Синтаксический анализатор DSQL можно заставить распознавать числовые строки как числа с плавающей точкой при использовании научной нотации — если добавить символ «е» или «Е» перед показателем степени, который может быть нулевым.

Например, DSQL распознает 16.92 как масштабируемое точное число и передаст его серверу в этой форме. С другой стороны, он будет трактовать 16.92Е0 как значение с плавающей точкой.

Типы данных с плавающей точкой

Типы данных с плавающей точкой служат «скользящими окнами» с точностью, подходящей масштабу числа. По своей природе в «плавающих» типах положение десятичной точки не зафиксировано — допустимо хранение в одном и том же столбце одного значения как 25.33333, а другого как 25.333. Эти значения различны и оба допустимы.

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

Числа с плавающей точкой могут быть использованы для представления значений, больших, чем это возможно для масштабируемых целых. Например, тип FLOAT может содержать числа с абсолютным значением не более 3.4Е38 (т. е. 34, за которым следует 37 нулей) и не менее 1.1Е-38 (37 нулей, 11 и затем десятичная точка).

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

Значение с плавающей точкой несет больше информации, чем указанное количество цифр точности. Например, тип FLOAT имеет точность 7 цифр, но его реальная точность 6 цифр. Последняя часть предоставляет дополнительную информацию о числе, такую как индикатор для округления и некоторые другие вещи, важные при выполнении арифметических операций с числом.

Например, FLOAT может содержать число 1000000000 (1 000 000 000 или 10(^9^)). «Контейнер» FLOAT рассматривает данное число как 100000*Е4. (Это лишь иллюстрация — полное представление реализации чисел с плавающей точкой выходит за рамки настоящей книги и очень далеко от того, что узнал автор!). Если вы прибавите 1 к значению FLOAT, то будет проигнорирована информация в седьмом разряде, потому что она не является значимой для текущего значения числа и его точности. Если же вы прибавляете 10 000 — число, которое значимо для хранимого в типе FLOAT числа, — то результатом может быть 100001*Е4.

Даже значения с подходящей точностью числа с плавающей точкой могут не всегда храниться в точном представлении. Такие значения, как 1.93 или даже 123, могут быть представлены в памяти как значения, очень близкие к указанному числу. Эти значения достаточно близки- когда число с плавающей точкой округляется для вывода, оно будет отображать ожидаемое значение, когда оно используется в вычислениях, результат будет очень близким приближением к ожидаемому результату.

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

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

Для сравнений проверяйте значения с плавающей точкой в предложении BETWEEN с подходящим диапазоном вместо того, чтобы выполнять точную проверку. Тот же совет применим и для сравнения с нулем — выберите подходящий диапазон значений и запишите проверку данных между нулем и близким к нулю значением или между двумя подходящими значениями, близкими к нулю^[23].

В базе данных диалекта 1 необходимость хранения значений числовых данных, имеющих больший диапазон, чем предоставляет 32-битовое целое, может быть решена выбором типа DOUBLE PRECISION. Ограничения диалекта 1 также требуют использования чисел с плавающей точкой для всех действительных чисел, если к базе данных предполагается доступ из встроенного приложения (ESQL).

Firebird предоставляет два приближенных числовых типа данных с плавающей точкой (FLOAT и DOUBLE PRECISION), отличающиеся только размером точности.

FLOAT

FLOAT является 32-битовым типом данных с плавающей точкой с приблизительно 7 цифрами точности — для надежности предполагайте 6 цифр. Число с 10 цифрами 25.33333312, добавленное в столбец FLOAT, сохраняется как 25.33333. Диапазон чисел от -3.402 x 10(^38^) до 3.402 x 10(^38^). Наименьшее положительное число, которое может быть сохранено, 1.175 * 10(^-38^).

DOUBLE PRECISION

DOUBLE PRECISION является 64-битовым типом данных с плавающей точкой с приблизительно 15 цифрами точности. Диапазон от -1.797 x 10(^308^) до 1.797 x 10(^308^). Наименьшее положительное число, которое может быть сохранено, 2.225 x 10(^-308^).

Арифметические операции над смешанными типами с фиксированной и плавающей точкой

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

Следующий оператор создает столбец PERCENT_CHANGE, используя тип DOUBLE PRECISION:

CREATE TABLE SALARY_HISTORY

(

. . .

PERCENT_CHANGE DOUBLE PRECISION

DEFAULT О

NOT NULL

CHECK (PERCENT_CHANGE BETWEEN -50 AND 50),

. . .

) ;

Следующий оператор CREATE TABLE дает пример использования различных числовых типов данных: INTEGER для общего количества заказов, с фиксированной точкой DECIMAL для общей суммы продаж в долларах и FLOAT для скидки к продаже:

CREATE TABLE SALES

(. . .

QTY_ORDERED INTEGER

DEFAULT 1

CHECK (QTY_ORDERED >=1),

TOTAL_VALUE DECIMAL (9,2)

CHECK (TOTAL_VALUE >= 0),

DISCOUNT FLOAT

DEFAULT 0

CHECK (DISCOUNT >= 0 AND DISCOUNT <= 1));

Пора дальше

В следующей главе мы рассмотрим типы данных для хранения и обработки дат и времени в Firebird.

ГЛАВА 10. Типы даты и времени.

Firebird поддерживает в диалекте 3 типы данных DATE, TIME и TIMESTAMP. В диалекте 1 поддерживается только один тип данных, подобный TIMESTAMP, который, хотя и называется DATE, не является взаимозаменяемым с типом DATE диалекта 3.

DATE

В диалекте 3 DATE хранит одну дату без времени — тип «только дата» — в виде 32-битового знакового целого. Хранимый диапазон дат от 1 января 0001 года до 31 декабря 9999 года^[24].

В диалекте 1 тип DATE эквивалентен типу TIMESTAMP диалекта 3. Действительно, когда вы создаете новый столбец даты в базе данных диалекта 1 с использованием isql, появляется предупреждение, информирующее вас, что тип данных был переименован! SQLTYPE будет иметь тип ISC_TIMESTAMP.

Не существует типа «только дата» в диалекте 1. Для сохранения в диалекте 1 только даты, передайте правильное значение даты и литерал времени в виде «00:00:00.0000». Литералы даты и времени обсуждаются более подробно в следующих разделах.

! ! !

СОВЕТ. Если вы используете isql для проверки дат диалекта 1, вы можете включать/выключать отображение времени при выводе даты, используя команду isql SET TIME. По умолчанию вывод времени отключен.

. ! .

TIMESTAMP

Тип данных TIMESTAMP диалекта 3 состоит из двух 32-битовых слов, хранящих дату и время. Данные хранятся как два 32-битовых целых, что эквивалентно типу DATE в диалекте 1.

Доли секунды

Доли секунды, если хранятся, являются десятитысячными долями секунды для всех типов даты и времени.

TIME

В диалекте 3 TIME хранит время дня без даты: «только время». Для хранения используется 32-битовое беззнаковое целое. Диапазон времени от 00:00 до 23:59:59.9999.

В диалекте 1 нет эквивалента типу TIME. Если нужно сохранить время дня, выделите элементы часов, минут и секунд из данных DATE и преобразуйте в строку. Технические советы есть дальше в этой главе — обратитесь к разд. «Комбинирование EXTRACT() с другими функциями».

Интервал времени

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

Предположим, что столбцы STARTED и FINISHED имеют тип TIMESTAMP (DATE В диалекте 1). Для вычисления и сохранения в столбце TIME_ELAPSED типа DOUBLE PRECISION интервала времени в минутах вы можете использовать следующее^[25]:

UPDATE ATABLE

SET TIME_ELAPSED = (FINISHED — STARTED) * 24 * 60

WHERE ((FINISHED IS NOT NULL) AND (STARTED IS NOT NULL));

Литералы даты

Литералы даты являются «читаемыми человеком» строками, заключенными в апострофы. Их сервер Firebird распознает как константы даты или даты-и-времени для EXTRACT и других выражений, операций INSERT и UPDATE, а также в предложении WHERE оператора SELECT.

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

* операторам SELECT, UPDATE и DELETE в условия поиска предложения WHERE;

* операторам INSERT и UPDATE для ввода констант даты и времени;

* аргументу FROM функции EXTRACT().

Распознаваемые форматы литералов даты и времени

Количество форматов строк, распознаваемых как литералы даты, ограничено. Эти форматы используют шаблоны для подстановки элементов строк. Табл. 10.1 описывает используемые соглашения.

Таблица 10.1. Элементы литералов даты

Элемент	Представление
CC	Столетие. Первые две цифры года (например, 20 для двадцать первого века)
YY	Год столетия. Firebird всегда сохраняет полное значение года, даже если год был введен без сегмента cc, при этом используется алгоритм «скользящего окна» для определения того, какое столетие сохранять
MM	Месяц- целое в диапазоне от 1 до 12. В некоторых форматах требуется две цифры
MMM	Месяц — один из [JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC] . Также допустимы полные английские названия месяцев
DD	День месяца- целое в диапазоне от 1 до 31. В некоторых форматах требуется две цифры. Неверное значение дня для конкретного месяца вызывает ошибку
HH	Часы — целое в диапазоне от 00 до 23. Требуются две цифры
NN	Минуты — целое в диапазоне от 00 до 59. Требуются две цифры
SS	Полные секунды — целое в диапазоне от 00 до 59. Требуются две цифры
nnnn	Десятитысячные доли секунды в диапазоне от 0 до 9999. Значение по умолчанию 0000. Если используется, то требуется четыре цифры

Распознаваемые форматы описаны в табл. 10.2.

Таблица 10.2. Распознаваемые форматы литералов даты и времени

Формат	Диалект 3 DATE	Диалект 3 TIMESTAMP	DATE
‘ CCYY-MM-DD’ или ‘YY-MM-DD’	Сохраняет только дату	Сохраняет дату и время в виде 00:00:00	Сохраняет дату и время в.виде 00:00:00
‘MM/DD/CCYY’ или ‘MM/DD/YY’	То же	То же	То же
‘DD.MM.CCYY’ или ‘DD.MM.YY’	То же	То же	То же
‘ DD-MMM-CCYY’ или ‘DD-MMM-YY’	То же	То же	То же
‘DD,MMM,CCYY’ или ‘ DD,MMM,YY’	То же	То же	То же
‘DD MMM CCYY’ или ‘DD MMM YY’	To же	То же	То же
‘DDMMMCCYY’ или ‘DDMMMYY’	To же	То же	То же

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

‘CCYY-MM-DD HH:NN:SS.nnnn’ или ‘YY-MM-DD HH:NN:SS.nnnn’ (элемент «.nnnn» необязателен)	Сохраняет толькодату; может потребовать преобразования для даты. Время не сохраняется	Сохраняет дату и время	Сохраняет дату и время
‘MM/DD/CCYYHH:NN:SS.nnnn’ или ‘MM/DD/YY HH:NN:SS.nnnn’	То же	То же	То же
‘ DD.MM.CCYYHH:NN:SS.nnnn’ или ‘DD.MM.YY HH:NN:SS.nnnn’	То же	То же	То же
‘DD-MMM-CCYY HH:NN:SS.nnnn’ или ‘DD-MMMYY HH:NN:SS.nnnn’	То же	То же	То же

Типы TIMESTAMP в диалекте 3 и DATE в диалекте 1 принимают дату и время в литерале даты. Литерал даты без времени будет сохранен и с временем в виде ‘ 00: 00: 00’.

Тип DATE в диалекте 3 принимает только дату. Тип данных TIME принимает только время.

«Скользящее окно века» в Firebird

Независимо от того, как представлена часть года в литерале DATE или TIMESTAMP, в виде CCYY или YY, Firebird всегда сохраняет полное значение года. Он обращается к алгоритму получения части cc (столетие). Он также всегда включает столетие при поиске типов даты. Клиентские приложения отвечают за отображение года в виде двух или четырех цифр.

Для получения столетия Firebird использует алгоритм скользящего окна. Задача заключается в интерпретации двухсимвольного значения года как ближайшего к текущему году в интервале предшествующих и последующих 50 лет.

Например, если текущий год 2004, то двухсимвольные значения года будут интерпретироваться, как показано в табл. 10.3.

Таблица 10.3. Определение года по двухсимвольному виду, если текущим является 2004 год

Двухсимвольный год	Полученный год	Рассчитывается как
98	1998	(2004 — 1998 = 6) < (2998 — 2004 = 94)
00	2000	(2004 — 2000 = 4) < (2100 — 2004 = 96)
45	2045	(2004 — 1945 = 55) > (2045 — 2004 = 41)
50	2050	(2004 — 1950 = 54) > (2050 — 2004 = 46)
54	1954	(2004 — 1954 = 50) = (2054 — 2004 = 50)*
55	1955	(2004 — 1955 = 49) < (2055 — 2004 = 51)

* Кажущееся равенство в этом сравнении может ввести в заблуждение. 1954 год ближе к 2004, чем 2054, потому что все даты между 1954 и 1955 годами ближе к 2004, чем все даты между 2054 и 2055 годами.

Разделители в неамериканских датах

Ничто не вызывает больше затруднений для интернациональных пользователей, как ограничения в Firebird на использование наклонной черты (/) только для американского формата ‘MM/DD/CCYY’. Хотя почти все другие страны используют формат ‘DD/MM/CCYY’, Firebird будет либо записывать неправильную дату, либо вызовет исключение для литерала даты, использующего соглашение ‘DD/MM/CCYY’.

Например, литерал даты ’12/01/2004′ всегда будет сохраняться в смысле «1 декабря 2004 года», а ’14/01/2004′ вызовет исключение выхода за границы диапазона, потому что не существует месяца 14. Однако допускается ‘CCYY/MM/DD’: дата ‘2004/12/31’ будет расшифровано как «31 декабря 2004 года».

Обратите внимание, что Firebird не учитывает локальные форматы даты Windows или Linux при интерпретации литералов даты (ни на сервере, ни на клиенте). Его интерпретация числовых форматов дат основывается на символе-разделителе. Если точка (.) используется в качестве разделителя, Firebird интерпретирует дату в виде неамериканской нотации DD.MM, в то время как любой другой разделитель предполагает американскую нотацию MM/DD. Чтобы убрать американскую интерпретацию даты, ваши приложения должны преобразовать введенную дату DD/MM/CCYY в литерал, где наклонная черта заменена на символ точки в качестве разделителя. Дата ‘DD.MM.CCYY’ правильная. Могут быть использованы и другие форматы литералов даты.

Пробелы в литералах даты

Пробелы или символы табуляции могут присутствовать между элементами. Дата должна быть отделена от времени, по меньшей мере, одним пробелом.

Заключение в апострофы литералов даты

Литералы даты должны быть заключены в апострофы (ASCII 39). Допустимы только апострофы, а не двойные кавычки.

Литералы месяца

В табл. 10.4 показаны литералы месяцев.

Таблица 10.4. Литералы месяцев и правильное английское написание

Число	Аббревиатура (не чувствительно к регистру)	Полное название месяца (не чувствительно к регистру)
01	JAN	January
02	FEB	February
03	MAR	March
04	APR	April
05	MAY	May
06	JUN	June
07	JUL	July
08	AUG	August
09	SEP	September
10	OCT	October
11	NOV	November
12	DEC	December

Примеры литералов даты

Двадцать пятое число (25) шестого месяца (июнь) 2004 года может быть представлено любым из следующих способов:

‘25.6.2004’ ’06/25/2004′ ‘June 25, 2004’

’25.jun.2004′ ‘6,25,2004’ ’25,jun,2004′

’25jun2004′ ‘6-25-04’ ‘Jun 25 04’

’25 jun 2004′ ‘2004 June 25’ ‘20040625’

’25-jun-2004′ ‘2004-jun-25’ ‘20040625’

’25 JUN 04′ ‘2004-06-25’ ‘2004,25,06’

Предварительно определенные литералы даты

Firebird поддерживает группу «предопределенных» литералов дат — английские слова, заключенные в апострофы, которые Firebird выбирает или вычисляет и интерпретирует в контексте соответствующего типа даты/времени. Слова ‘TODAY’, ‘NOW, ‘YESTERDAY’ и ‘TOMORRROW интерпретируются, как показано в табл. 10.5.

Таблица 10.5. Предварительно определенные литералы даты

Литерал	Тип диалекта 3	Тип диалекта 1	Значение
‘NOW’	TIMESTAMP	DATE	Дата и время сервера, которые были текущими на момент старта операции DML. ‘NOW’ будет преобразовано и корректно сохранено в полях DATE, TIME и TIMESTAMP В диалекте 3 или в полях DATE в диалекте 1. Как и эквивалентная контекстная переменная CURRENT_TIMESTAMP, значение всегда сохраняется с долями секунды ‘ .0000’ *
‘ TODAY’	DATE	DATE хранится с временем равным ’00:00:00′	Дата и время сервера, которые были текущими на момент старта операции. Если в процессе операции миновала полночь, дата не изменяется. Эквивалентен контекстной переменной диалекта 3 CURRENT_DATE. Недопустим для полей типа TIME
‘TOMORRROW’	DATE	DATE хранится с временем равным ’00:00:00′	Дата и время сервера, которые были текущими на момент старта операции, плюс 1 день. Если в процессе операции миновала полночь, дата, из которой была вычислена дата ‘TOMORRROW’, не изменяется. Недопустим для полей типа TIME
‘YESTERDAY’	DATE	DATE хранится с временем равным ’00:00:00′	Дата и время сервера, которые были текущими на момент старта операции, минус 1 день. Если в процессе операции миновала полночь, дата, из которой была вычислена дата ‘YESTERDAY’, не изменяется. Недопустим для полей типа TIME

* Тем не менее ничто не теряется. Вы можете получить дату и время сервера с десятитысячными долями секунды, используя UDF GetExactTimestamp (…) из библиотеки UDF Firebird. Более подробную информацию см. в приложении 1.

Неявное преобразование типов в литералах даты и времени

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

Например, совершенно верным является затребовать, чтобы запрос SELECT вернул константу, которая не связана ни с каким столбцом в базе данных. Основное «хакерство» в Firebird- использование системной таблицы RDB$DATABASE в запросе, поскольку эта таблица имеет одну и только одну строку, и всегда можно получить скалярное значение: единственное контекстное значение от сервера. Следующие два примера иллюстрируют типичное использование этого приема:

SELECT ‘NOW’ FROM RDB$DATABASE;

Так как запрос возвращает константу, а не значение столбца, ее тип данных интерпретируется как CHAR(3), ‘NOW’. Этот пример

SELECT ‘2.09.2004’ FROM RDB$DATABASE;

вернет CHAR(9), ‘2.09.2004’.

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

* для диалекта 3:

SELECT CAST(‘NOW’ AS TIMESTAMP) FROM RDB$DATABASE;

SELECT CAST(‘2.09.2004’ AS TIMESTAMP) FROM RDB$DATABASE;

* для диалекта 1:

SELECT CAST(‘NOW’ AS DATE) FROM RDB$DATABASE;

SELECT CAST(‘2.09.2004’ AS DATE) FROM RDB$DATABASE;

Контекстные переменные даты и времени

Контекстные переменные даты и времени CURRENT_DATE, CURRENT_TIME и CURRENT_TIMESTAMP возвращают значение даты и времени, полученные с сервера на момент начала выполнения оператора SQL, содержащего контекстную переменную. Табл. 10.6 описывает эти переменные.

Таблица 10.6. Контекстные переменные даты и времени

Переменная	Тип диалекта 3	Тип диалекта 1	Значение
CORRENT_TIMESTAMP	TIMESTAMP	DATE	Текущая дата и время, округленное до секунд. Дробная часть секунд всегда возвращается равной ‘.0000’
CURRENT_DATE	DATE	Не поддерживается	Текущая дата
CURRENT_TIME	TIME	Не поддерживается	Текущее время, выраженное в часах, минутах и секундах после полуночи. Дробная часть секунд всегда возвращается равной ‘ .0000’

Операции, использующие значения даты и времени

Использование арифметических операций в манипулировании данными, в вычислениях и в отношениях между двумя датами были ранее рассмотрены в разд. «Интервал времени» этой главы. Возможность вычитания значения более ранней даты, времени или даты-времени из более поздней существует благодаря способу хранения типов дата и время в Firebird. Способ хранения использует одно или два 32-битовых целых для даты/времени, только для даты или только для времени дня. Данные, представленные в этих числах, являются днями в длинном слове даты и дробной частью дней в слове времени. Дата представлена количеством дней с «нулевой даты»- 17 ноября 1898 г^[26]. Время представлено в десятитысячных долях секунд, прошедших с полуночи.

В диалекте 3 DATE хранит только дату. В диалекте 3 TIME хранит только время. TIMESTAMP и в диалекте 1 DATE хранят обе части.

С этими числовыми структурами можно довольно просто оперировать, используя несложные выражения сложения и вычитания для вычисления разницы во времени (интервал), увеличения или уменьшения дат, установления диапазонов даты или времени. В табл. 10.7 описываются доступные операции и получаемые результаты.

Таблица 10.7. Арифметические операции для типов данных даты и времени

Операнд 1	Оператор	Операнд 2	Результат
DATE	+	TIME	TIMESTAMP (арифметическая конкатенация)
DATE	+	Числовое значение n**	DATE, увеличенная на n целых дней (игнорируется дробная часть n, если указана)
TIME	+	DATE	TIMESTAMP (арифметическая конкатенация)
TIME	+	Числовое значение n**	TIME, увеличенное на n секунд*
TIMESTAMP	+	Числовое значение n**	TIMESTAMP, где дни увеличены на целую часть числа n плюс дробная часть числа n (если указана) как количество десятитысячных долей секунды в дне (8.64 x 10(^5^))
DATE	—	DATE	Количество дней в интервале: DECIMAL(9,0)
DATE	—	Числовое значение N**	DATE, уменьшенная на n дней (игнорируется дробная часть n, если указана)
TIME	—	TIME	Количество секунд в интервале: DECIMAL(9,4)
TIME	—	Числовое значение n**	TIME, уменьшенное на n секунд*
TIMESTAMP	—	TIMESTAMP	Количество дней и части дня в интервале: DECIMAL (18, 9)
TIMESTAMP	—	Числовое значение n**	TIMESTAMP, где дни уменьшены на целую часть числа n плюс дробная часть числа n (если указана) как количество десятитысячных долей секунды в дне (8.64×10(^5^))

* При необходимости повторяется (result=modulo(result, (24*60*60))) пока не будет выделена результирующая часть дней.

** В диалекте 3 для типа DATE n является целым, представляющим количество дней. Для типов данных TIMESTAMP и для диалекта 1 DATE n может быть числом, представляющим количество дней слева от десятичной точки (целая часть) и части дня справа от десятичной точки (дробная часть). Для типа TIME n является целым числом, представляющим количество секунд.

Общие правила для операций

Одно значение даты или времени может быть вычтено из другого, если:

* оба значения имеют один и тот же тип даты/времени;

* первый операнд является более поздним, чем второй.

Вычитание, использующее типы дата/время, дает результаты: масштабируемое DECIMAL в диалекте 3 и DOUBLE PRECISION В диалекте 1.

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

* дополнительный бинарный синтаксис для конкатенации пар полей или переменных;

* объединение строк для конкатенации литерала дата/время с другим литералом дата/время или с полем, или переменной типа дата/время.

Операции умножения и деления, включающие типы данных дата/время, недопустимы.

Выражения в качестве операндов

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

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

В табл. 10.8 показаны некоторые примеры.

Таблица 10.8. Примеры использования выражений в качестве операндов

Вводимый операнд n	Сложение или вычитание	Альтернатива
В секундах	n/86400.0	(n1,0)/(60 60*24)
В минутах	n/1440.0	(n1.0)/(6024)
В часах	n/24.0	Зависит от желаемого результата. Например, если n=3, а делитель для половины дня — 2, результат будет 1, а не 1.5
Половина дня	n/2	То же

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

Использование CAST() с типами дата/время

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

Преобразование между типами дата/время

Обычно преобразование из одного типа дата/время в другой возможно, если исходный тип дата/время содержит подходящий вид данных для помещения в выходной тип дата/время. Например, TIMESTAMP содержит данные, которые можно преобразовать в тип только даты DATE или только время TIME, В то время как тип TIME не содержит достаточно данных для преобразования в тип DATE. Firebird предоставляет возможность преобразовывать тип DATE В TIMESTAMP, присваивая времени значение полночи, и тип TIME в TIMESTAMP, выбирая дату из контекстной переменной CURRENT_DATE (серверное время). В табл. 10.9 представлены правила преобразования.

Таблица 10.9. Преобразования между типами дата/время в диалекте 3

Исходный тип	В тип TIMESTAMP	В тип DATE	В тип TIME
TIMESTAMP	Недоступно	Да, преобразует дату, игнорируя время	Да, преобразует время, игнорируя дату
DATE	Да, время устанавливается в значение полночи	Недоступно	Нет
TIME	Да, дате присваивается значение CURRENT_DATE	Нет	Недоступно
DATE + TIME	Да, CAST ( (DATEFIELD + TIMEFIELD AS TIMESTAMP)	Нет	Нет

Преобразование типов даты в CHAR(n) и VARCHAR(n)

Используйте в операторах SQL-функцию CAST() для трансляции данных даты и времени в символьные типы данных.

Firebird преобразует типы дата и время в форматированные строки, в которых дата (если присутствует) представлена в установленном формате — в зависимости от диалекта — а время представлено в стандартном для Firebird формате: HH:MM:ss.nnnn. Необходимо использовать столбец, переменную типа CHAR или VARCHAR подходящего размера для получения желаемого вами результата.

Преобразование типов дата/время можно выполнять в оба строковых типа фиксированной длины CHAR и переменной длины VARCHAR. Поскольку размер преобразуемой строки заранее известен, CHAR имеет небольшое преимущество перед VARCHAR: использование CHAR при передаче по сети сэкономит вам два байта, которые добавляются к VARCHAR для хранения размера. «Правильный размер» зависит от диалекта, обратите на это внимание, VARCHAR может быть более подходящим при использовании в коде приложения, которое может обрабатывать оба диалекта.

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

Диалект 3

Преобразование DATE или TIMESTAMP создает дату в формате ISO (CCYY-MM-DD). Полная длина выходной строки 10 символов для DATE и 11 — для TIMESTAMP (дата и один пробел перед временем). Нужно 13 символов для TIME или для времени в TIMESTAMP.

Например, выражение

SELECT CAST(timestamp_col as CHAR(24)) AS TstampTxt FROM RDB$DATABASE;

даст строку вроде следующей:

2004-06-25 12:15:45.2345

Это выдаст исключение переполнения:

SELECT CAST (timestamp_col as CHAR(20)) AS TstampTxt FROM RDB$DATABASE;

Двойное преобразование создает правильную строку:

SELECT FIRST 1 CAST (

CAST (timestamp_col AS DATE) AS CHAR(10)) FROM Table1;

Результатом будет:

2004-06-25

К сожалению, нет возможности путем прямого преобразования получить строку, содержащую дату плюс время без дробных долей секунды. Это может быть выполнено с использованием сложного выражения, включающего функции CAST() и EXTRACT(). Пример см. в одном из следующих подразделов разд. «Функция EXTRACT()».

Диалект 1

Дата в типе данных DATE диалекта 1 преобразуется в формат DD-MMM-CCYY, а не В формат ISO, как в диалекте 3. Например, вот это

SELECT CAST(dldate_col as CHAR(25)) AS DateTimeTxt FROM RDB$DATABASE;

даст

26-JUN-2004 12:15:45.2345

Следовательно, преобразование дат в диалекте 1 требует 11 символов вместо 10 плюс 1 символ пробела плюс 13 для времени — всего 25.

Более сложные выражения

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

SELECT CAST (10 + CAST((‘TODAY’) AS DATE) AS CHAR(25)) TEXTTIME FROM RDB$DATABASE;

или

SELECT CAST (10 + CURRENT_TIMESTAMP) AS DATE) AS CHAR(25)) TEXTTIME FROM RDB$DATABASE;

возвращает текстовую строку, показывающую дату на 10 дней позже текущей даты.

Преобразования между типами дата/время и другими типами данных

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

Типы данных времени и даты не могут быть участниками преобразований в типы или из типов SMALLINT, INTEGER, FLOAT, DOUBLE_PRECISION, NUMERIC, DECIMAL или BLOB.

Использование преобразований

Обмен данными дата/время с другими приложениями

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

Большинство включающих языков программирования не поддерживают типы данных DATE, TIME и TIMESTAMP, представляя их внутренне в виде строк или структур. Устройства ввода данных обычно сохраняют дату и время в строках различных форматов и стилях. Типы дата/время чаще всего являются несовместимыми в различных базах данных.

Преобразование обычно требует вычисления и декодирования содержимого элементов даты в исходных данных. Второй частью процесса является реконструкция декодированных элементов и передача их SQL Firebird каким-нибудь способом. Во включающем языке, в котором не существует никакого способа передачи типов данных дата/время Firebird, использование функции CAST() в комбинации с допустимыми текстовыми строками для обработки в Firebird в качестве литералов даты может оказаться очень полезным^[27].

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

Функция CAST() также может быть использована для подготовки внутренних данных для экспорта.

Использование в выражениях условия поиска

Такие ситуации появляются, когда использование CAST() в предложении WHERE с типами дата/время решает логические проблемы сравнения столбца одного типа со столбцом другого типа данных.

Предположим, что нам нужно объединить таблицу покупателей, которая содержит столбец BALANCE_DATE типа DATE с таблицей транзакций покупателя, которая имеет столбец TRANSUDATE типа TIMESTAMP. Нам нужно создать предложение WHERE, которое выбирает набор данных, содержащий неоплаченные транзакции для текущего покупателя, появившиеся не позднее BALANCE_DATE. Мы можем попытаться:

SELECT …

WHERE COST_TRANS.TRANSDATE <= CUSTOMER.BALANCE_DATE ;

Этот критерий не даст нам того, что мы хотим! Он найдет все строки транзакций после полуночи даты BALANCE_DATE, потому что он вычислит BALANCE_DATE с временем 00:00:00. Любая транзакция после полуночи этой даты не будет соответствовать критерию поиска.

Что мы действительно хотим, так это включить все транзакции, где дата из TRANS DATE соответствует BALANCE_DATE. Преобразование TRANSUDATE в тип DATE сохраняет день:

SELECT …

WHERE CAST (CUST_TRANS.TRANSDATE AS DATE) <= CUSTOMER.BALANCE_DATE;

Использование в преобразовании диалекта

Диалект 3 предоставляет более богатую поддержку типов дата/время, чем диалект 1. Одной из задач, которая, скорее всего, привлечет ваше внимание, если вы выполняете такое преобразование, является замена существующих в диалекте 1 столбцов типа DATE (который эквивалентен типу TIMESTAMP в диалекте 3) путем преобразования их в типы данных диалекта 3 DATE (только дата) или TIME (только время), CAST() легко выполняет эту работу.

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

Функция EXTRACT()

Функция EXTRACT() возвращает различные элементы, выделенные путем декодирования полей типов дата/время. Она может работать с полями дата/время в диалекте 3 и в диалекте 1.

Синтаксис

Синтаксис функции EXTRACT():

EXTRACT (элемент FROM поле)

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

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

Табл. 10.10 показывает ограничения на аргументы и их типы данных при использовании функции EXTRACT().

Таблица 10.10. Аргументы, типы и ограничения функции EXTRACT()

Элемент	Тип данных	Ограничения	TIMESTAMP/ диалект 1 DATE	DATE	TIME
YEAR	SMALLINT	0-5400	Допустимо	Допустимо	Не допустимо
MONTH	SMALLINT	1-12	Допустимо	Допустимо	Не допустимо
DAY	SMALLINT	1-31	Допустимо	Допустимо	Не допустимо
HOUR	SMALLINT	0-23	Допустимо	Не допустимо	Допустимо
MINUTE	SMALLINT	0-59	Допустимо	Не допустимо	Допустимо
SECOND	DECIMAL(6,4)	0-59.9999	Допустимо	Не допустимо	Допустимо
WEEKDAY	SMALLINT	0-6*	Допустимо	Допустимо	Не допустимо
YEARDAY	SMALLINT	1-366	Допустимо	Допустимо	Не допустимо

* 0 = воскресенье … 6 = суббота.

Объединение EXTRACT() с другими функциями

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

Получение даты и времени без долей секунды

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

Выделение строки времени

Эта техника больше нужна в диалекте 1, чем в диалекте 3. Тем не менее она может быть экстраполирована на любой тип даты или времени диалекта 3, если вам нужно сохранять время дня в виде строки.

Функция EXTRACT() делает возможным выделение отдельных элементов типов даты и времени в значения SMALLINT. Следующий триггер выделяет элементы времени из столбца диалекта 1 DATE с именем CAPTURE_DATE и преобразует их в CHAR (13), имитируя стандартный в Firebird литерал времени ‘HH:MM:ss.nnnn’.

SET TERM ^;

CREATE TRIGGER BI_ATABLE FOR ATABLE

ACTIVE BEFORE INSERT POSITION 1

BEGIN

IF (NEW.CAPTURE_DATE IS NOT NULL) THEN

BEGIN

NEW. CAPTURE_TIME =

CAST(EXTRACT (HOUR FROM NEW.CAPTUEE_DATE) AS CHAR(2)) || ‘:’ ||

CAST(EXTRACT (MINUTE FROM NEW.CAPTURE_DATE) ASCHAR(2)) || ‘:’ ||

CAST(EXTRACT (SECOND FROM NEW.CAPTURE_DATE) AS CHAR(7));

END

END ^

SET TERM ; ^

Пример преобразования типа дата/время

Строка CHAR (13), сохраняемая триггером в предыдущем примере, не имеет того «поведения,» что тип TIME в диалекте 3. Тем не менее при простом преобразовании она может быть конвертирована напрямую в тип TIME диалекта 3 при последующем обновлении до диалекта 3.

Сначала мы добавляем новый временный столбец в таблицу для хранения конвертированной строки времени:

ALTER TABLE ATABLE

ADD TIME_CAPTURE TIME;

COMMIT;

Затем заполняем временный столбец строкой времени, выполняя преобразование в диалекте 1:

UPDATE ATABLE

SET TIME_CAPTURE = CAST (CAPTURE_TIME AS TIME)

WHERE CAPTURE_TIME IS NOT NULL;

COMMIT;

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

SET TERM ^;

RECREATE TRIGGER BI_ATABLE FOR ATABLE

ACTIVE BEFORE INSERT POSITION 1

BEGIN

/* ничего не выполняется */

END ^

SET TERM ;^

COMMIT;

Теперь мы можем удалить старый столбец CAPTURE_TIME:

ALTER TABLE ATABLE DROP CAPTURE_TIME;

COMMIT;

Создадим его опять, на этот раз как тип TIME:

ALTER TABLE ATABLE

ADD CAPTURE_TIME TIME;

COMMIT;

Перепишем данных из временного столбца в только что добавленный столбец

CAPTURE_TIME:

UPDATE ATABLE

SET CAPTURE_TIME = TIME_CAPTURE

WHERE TIME_CAPTURE IS NOT NULL;

COMMIT;

Удалим временный столбец:

ALTER TABLE ATABLE DROP TIME_CAPTURE;

COMMIT;

Под конец изменим триггер так, чтобы он теперь записывал значение CAPTURE_TIME как тип TIME:

SET TERM ^;

RECREATE TRIGGER BI_ATABLE FOR ATABLE

ACTIVE BEFORE INSERT POSITION 1

BEGIN

IF (NEW.CAPTURE_DATE IS NOT NULL) THEN

BEGIN

NEW.CAPTURE_TIME = CAST (NEW.CAPTURE.DATE AS TIME);

END

END ^

SET TERM ;^

COMMIT;

Все эти шаги могут быть записаны в скрипте SQL. Подробности использования скриптов SQL см. в разд. «Скрипты схемы» главы 14.

Понимание функции EXTRACT()

Функция EXTRACT() вызывает исключение, если она получает пустой аргумент. Этот факт можно использовать в простых запросах для проверки условия NOT NULL или в выражениях подзапросов при декодировании полей типа дата/время. Тем не менее во внешних соединениях это не столь просто, потому что потоки внешнего соединения, которые не соответствуют условиям последнего, возвращают NULL в незаполненных полях.

Рекомендуется использовать подзапрос (см. главы 21 и 22), который ограничивает вызовы функции только при ненулевых значениях. В диалекте 3 есть другое решение: использовать выражение CASE (см. главу 21) для исключения вызова EXTRACT() при нулевых датах.

Пора дальше

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

ГЛАВА 11. Символьные типы данных.

Firebird поддерживает символьные (строковые) типы данных фиксированной и переменной длины. Они могут быть определены для локального использования в любом наборе символов, выбираемом из большого списка. Символьные типы фиксированной длины не могут превышать 32 767 байт абсолютной длины; для типов переменной длины этот предел уменьшается на два байта, которые при сохранении строки содержат счетчик символов.

Firebird хранит строки очень экономно, используя простой алгоритм сжатия данных, даже если это тип CHAR или NCHAR. В том случае, когда вы хотите объявить очень большой строковый столбец, помните, что существует множество причин не использовать длинные строки — ограничения клиентской памяти или размеров индекса, а для Firebird 1.0.x еще и декомпрессия строк фиксированной и переменной длины в объявленную длину до того, как они покинут сервер.

Основы использования строк

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

! ! !

ПРИМЕЧАНИЕ. Атрибут CHARACTER SET в объявлении является необязательным. Если никакой набор символов не определяется на уровне столбца, то атрибут CHARACTER SET устанавливается в значение набора символов по умолчанию для базы данных. Механизм определения набора символов для столбцов и переменных обсуждается более подробно позже в этой главе.

. ! .

Попытка помещения в строковый столбец Firebird строки с длиной, превышающей объявленную, вызывает ошибку переполнения.

Ограничитель строки

Ограничителем строк в Firebird является символ ASCII 39, или одиночная кавычка, или апостроф, например,

StringVar = ‘This is a string.’;

Двойные кавычки вовсе запрещены для ограничения строк. Вы должны помнить это, если соединяетесь с БД Firebird, используя код приложения, написанного для баз данных InterBase 5, где разрешалось использовать кавычки в качестве ограничителя строк. Строки должны быть исправлены также в исходном коде хранимых процедур и триггеров в базе данных InterBase 5, если вы планируете перекомпилировать их для Firebird.

Конкатенация

Firebird использует стандартный в SQL символ для конкатенации (соединения) строк: двойной символ ASCII с кодом 124, известный как двойная вертикальная черта (||). Он может быть использован для конкатенации строковых констант, строковых выражений и/или значений столбцов, например:

MyBiggerString = ‘You are my sunshine, ‘ || FirstName || ‘ my only sunshine.’;

Символьные элементы могут соединяться с числами и числовыми выражениями для получения алфавитно-цифровых строк. Например, для конкатенации символа ‘#’ с целым:

NEW.TICKET_NOMBER = ‘#’ || NEW.PK_INTEGER;

! ! !

ВНИМАНИЕ! He используйте выражения конкатенации, где один из элементов может иметь значение NULL. Результатом любой конкатенации, содержащей NULL, будет NULL.

. ! .

Управляющие символы

Как правило, Firebird не поддерживает использование управляющих символов для включения непечатаемых кодов или последовательностей в строковые поля. Единственным исключением является «дублирование» символа апострофа (ASCII 39) для включения его в качестве хранимого символа и исключения его интерпретации как терминального ограничителя строки:

. . .

SET HOSTELRY = ‘О»Flaherty»s Pub’

. . .

В строках можно хранить непечатаемые символы. Может быть объявлена функция UDF Asciichar (ascii_значение) в библиотеке ib udf, чтобы дать возможность передавать в строки такие символы или их последовательности. Следующий оператор выводит множество текстовых полей — например, во внешний файл — с символами возврата каретки и перевода строки в последнем поле:

INSERT INTO EXTFILE(DATA1, DATA1, DATA3, CRLF)

VALUES (‘String1’, ‘String2’, ‘String3’, Ascii_Char(13) || Ascii_Char(10));

По поводу объявления Asciichar (..) и других функций в библиотеке ib udf смотрите в подкаталоге ../UDF в корневом каталоге инсталляции Firebird скрипт с именем ib udf.sql. Подробности о внешних функциях см. в приложении 1.

Ограничения символьных типов

Ограничения многобайтовых наборов символов

Важно быть в курсе того, как многобайтовые наборы символов влияют на размеры текстовых элементов, особенно имеющих переменный размер. Например, в наборе символов UNICODE FSS даже 256-символьный столбец будет иметь больший размер — потенциально 770 байт- как для хранения данных, так и для поиска. Дальше в этой главе будет много сказано об осторожности, которую вы должны проявить, решая вопрос о хранении текстов для многобайтовых наборов символов.

Ограничения индексов

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

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

Использование памяти клиента

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

Рассмотрим, например, какое влияние окажет на рабочую станцию запрос, возвращающий 1024 строки, каждая из которых содержит один столбец, объявленный как VARCHAR(1024) . Даже с самым «скромным» набором символов этого столбца потребуется, по меньшей мере, 1 Мбайт памяти клиента. Для столбца Unicode умножьте эту величину на три.

Символьные данные фиксированной длины

Строковые типы данных фиксированной длины в Firebird используются для хранения строк, длина которых является одной и той же или очень близкой, либо там, где фор- мат или относительная позиция символов может передавать семантическое содержание. Обычно они применяются для таких элементов, как идентификационные коды, номера удаленной связи, базирующиеся на символах цифровые системы, а также для объявления полей с целью хранения предварительно форматированных строк фиксированной длины, чтобы конвертировать их в другие типы данных — например, литералы даты Firebird.

Начальные символы пробелов (символ ASCII 32) во вводимых строках фиксированной длины являются значимыми, в то время как завершающие — нет. При сохранении строк фиксированной длины Firebird убирает конечные пробелы. Строки отыскиваются без избыточного расширения до объявленной длины.

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

CHAR(n), алиас для CHARACTER(n)

CHAR(n), алиас для CHARACTER(n), является основой символьного типа фиксированной длины, n представляет точное количество хранимых символов. Этот тип данных может хранить строки любого поддерживаемого набора символов.

! ! !

ПРИМЕЧАНИЕ. Если аргумент длины, n, в объявлении отсутствует, то предполагается CHAR(1). Допустимо объявлять односимвольные поля CHAR как просто CHAR.

. ! .

NCHAR(n), алиас для NATIONAL CHARACTER(n)

NCHAR (n), алиас для NATIONAL CHAR(11) , является специализированной реализацией типа CHAR(n) с предварительно установленным атрибутом набора символов iso8859_1. Естественно, недопустимо определять атрибут набора символов для столбца NCHAR, хотя последовательность сортировки — последовательность, в которой будут сортироваться символы для поиска упорядочения вывода, — может быть объявлена для столбца или домена, которые используют этот тип.

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

Символьные данные переменной длины

Строковые типы данных переменной длины в Firebird используются для хранения строк, длина которых может изменяться. Обязательный аргумент размера n ограничивает количество символов, которые могут храниться в столбце максимум n символами. Размер типа VARCHAR не может превышать 32 765 байтов, потому что Firebird добавляет два байта к размеру элемента для каждого объекта VARCHAR.

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

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

Транспортировка в сети

До Firebird 1.5 найденные текстовые элементы данных переменной длины дополнялись на сервере до полного, объявленного размера до передачи клиенту. Начиная с Firebird 1.5, данные не дополняются. На момент написания этой книги такая возможность для текстов переменной длины не была выполнена для Firebird 1,0.x, что может повлиять на ваш выбор размера и типа столбца, если вы пишете приложения для удаленных клиентов, соединяющихся с сервером 1,0.x в медленной сети.

Хотя типы переменной длины могут хранить строки почти в 32 Кбайтах, на практике не рекомендуется использовать их для элементов данных, длиннее, чем 250 байт, особенно если их таблицы будут увеличиваться в размерах или если они часто будут субъектом запросов SELECT. Тип данных BLOB с подтипом SUB_TYPE 1 (текст) обычно лучше подходит для хранения больших строковых данных. Тексты BLOB подробно обсуждаются в следующей главе.

VARCHAR(n), алиас для CHARACTER VARYING(n)

VARCHAR(n), алиас для CHARACTER VARYING(n), является базовым строковым типом переменной длины, n представляет максимальное количество символов, которое может сохраняться в столбце. Этот тип хранит строки любого поддерживаемого набора символов. Если никакой набор символов не указан, атрибут примет значение набора символов по умолчанию, который был определен в операторе CREATE DATABASE в предложении DEFAULT CHARACTER SET. ЕСЛИ не существует набора символов по умолчанию, то столбец получит CHARACTER SET NONE.

NCHAR VARYING(n), алиас для NATIONAL CHAR VARYING(n)

NCHAR VARYING(N), алиас для NATIONAL CHAR VARYING(N), который в свою очередь является алиасом для NATIONAL.CHARACTER VARYING(N) — это специализированная реализация типа VARCHAR(n) с предварительно установленным атрибутом набора символов ISO8859_1. Недопустимо определять атрибут набора символов для столбца NCHAR VARYING, хотя последовательность сортировки — последовательность, в которой будут сортироваться символы для поиска упорядочения вывода — может быть объявлена для столбца или домена, которые используют этот тип.

Наборы символов и последовательность сортировки

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

* символы, которые могут быть использованы в столбцах CHAR, VARCHAR и BLOB SUB_TYPE | (текст);

* число байтов, выделяемых для каждого символа;

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

Если для столбца вы не укажете набор символов, то для него будет использован набор символов по умолчанию базы данных. Если для базы данных не указан набор символов по умолчанию, то столбец получит значение CHARACTER SET NONE. ЕСЛИ ваша база данных используется в окружении, где присутствует только английский язык, у вас может появиться соблазн не использовать набор символов. Не соблазняйтесь! Набор символов NONE безропотно примет любые однобайтовые символы. Проблемы появятся- в неанглийском окружении или при наличии смешанных языков- вы получите ошибку транслитерации при выборе ваших текстовых данных. То, что уходит, не всегда то же самое, что приходит!

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

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

Помимо набора символов различные страны, языки и даже культурные группы, применяющие то же самое распределение символов, используют различные последовательности для определения «алфавитно-цифрового порядка» для сортировки и сравнений. Следовательно, для большинства наборов символов Firebird предоставляет множество последовательностей сортировки. Некоторые последовательности сортировки также учитывают пары прописные/строчные буквы для решения задачи упорядочивания, не чувствительного к регистру. Предложение COLLATE используется в отдельных контекстах, где важна последовательность сортировки, хотя оно и не

объявляется на уровне базы данных.

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

Набор символов клиента

Что по-настоящему имеет значение в отношении наборов символов — это взаимодействие между сервером и клиентом. Клиентская библиотека Firebird должна передавать атрибут набора символов как часть параметров запроса на соединение.

Если сервер обнаруживает различие между установленным для клиента набором символов и хранимым в базе данных, то автоматически будет выполнена трансляция — «транслитерация» — в предположении, что входящие коды являются корректными для клиентской кодовой страницы. Входящие коды будут преобразовываться в коды, корректные для соответствующих символов в наборе символов объекта хранения.

Это делает возможным хранение текстов в различных объектах, которые имеют наборы символов, отличные от набора символов базы данных по умолчанию.

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

Более подробную информацию об ошибках транслитерации и их исправлении см. в разд. «Транслитерация » далее в этой главе.

Приложения, подключающиеся к базе данных, должны передавать набор символов базы данных в API через блок параметров базы данных (Database Parameter Block, DPB) в параметре isc_dpb_ic_ctype. Приложение ESQL — включая утилиту isql — должно выполнить оператор SET NAMES непосредственно перед оператором CONNECT. Команда SET NAMES <набор-символов> используется для установки набора символов в утилите isql. Графический интерфейс инструментов администратора обычно предоставляет возможность выбора или явного указания клиентского набора символов.

Если вам нужно использовать язык, отличный от английского, потратьте некоторое время на изучение доступных наборов символов и выбора того, который наиболее соответствует вашим требованиям к вводу, хранению и выводу текстов. Не забудьте включить этот набор символов в атрибуты базы данных при создании базы данных. Синтаксис см. в разд. «Обязательные и необязательные атрибуты» главы 15. Список наборов символов, распознаваемых Firebird, см. в приложении 8.

Переопределение набора символов

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

! ! !

ВНИМАНИЕ! Когда столбцы используют значение набора символов по умолчанию для базы данных, изменение набора символов по умолчанию для базы данных повлияет только на вновь создаваемые столбцы и домены. Существующие столбцы сохранят имеющееся значение набора символов.

. ! .

Наборы символов Firebird

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

* происхождение наборов символов;

* глобальные наборы символов по умолчанию для базы данных;

* альтернативные наборы символов и последовательности сортировки для доменов и столбцов;

• последовательности сортировки для:

• текстовых значений в операциях сравнения;

• предложений ORDER BY и GROUP BY;

• как указать серверу необходимость трансляции вводимых данных в конкретный набор символов.

Набор символов является собранием символов, который включает, по меньшей мере, один репертуар символов. Репертуар символов является набором символов, используемым в конкретной культуре для публикаций, письменной коммуникации и — в контексте базы данных — для компьютерного ввода и вывода. Например, ISO Latin 1 является набором символов, который охватывает английский (А, В, С … Z) и французский (А, А, А, В, С, Q, D … Z) репертуары, делающие его полезным для обоих сообществ.

Именование наборов символов

Большинство наборов символов Firebird определены на основании стандартов и их имена близко соответствуют этим стандартам. Например, Microsoft определяет Windows 1251, a Firebird реализует его как WIN1251. Набор символов ISO8859_1 является «набором символов, определенным в стандарте ISO 8859-1, кодированным значениями, определенными в стандарте ISO 8859-1, каждое значение представлено одним 8-битовым байтом».

Алиасы

Имена алиасов наборов символов поддерживают разницу в именовании стандартов между платформами. Например, если вы найдете, что в операционной системе используется идентификатор WIN 1251 для набора символов WIN1251, вы можете использовать алиас, определенный в системной таблице RDB$TYPES, как описано в следующем разделе.

Хранение наборов символов и алиасов

Наборы символов в настоящий момент «зашиты» в базу данных с момента ее создания. Одной из системных таблиц, создаваемых автоматически, является RDB$CHARACTER_SET. Для отображения имен наборов символов с последовательностью сортировки каждого из них выполните запрос:

SELECT

RDB$CHARACTER_SET_NAME,

RDB$DEFAULT_COLLATE_NAME,

RDB$BYTES_PER_CHARACTER

FROM RDB$CHARACTER_SETS

ORDER BY 1 ;

Если требуется, алиасы помещаются в RDB$TYPES- другую системную таблицу, которая хранит список алиасов, используемых сервером базы данных. Для просмотра всех алиасов, которые были установлены во время создания базы данных, выполните следующий запрос, который фильтрует RDB$TYPES для просмотра только имен наборов символов:

SELECT

С. RDB$CHARACTER_SET_NAME,

T.RDB$TYPE_NAME

FROM RDB$TYPES T

JOIN RDB$CHARACTER_SETS С

ON C.RDB$CHARACTER_SET_ID = T.RDB$TYPE

WHERE T.RDB$FIELD_NAME = ‘RDB$CHARACTER_SET_NAME’

ORDER BY 1 ;

! ! !

ПРИМЕЧАНИЕ. Для того чтобы использовать наборы символов, отличные от NONE, ASCII, OCTETS и UNICODE_FSS, необходимо иметь библиотеку fbintl в каталоге /intl корневого каталога Firebird.

. ! .

Ограничения хранения

Важно понимать, как ваш выбор набора символов влияет на хранение планируемых вами ограничений для данных. В случае столбцов CHAR и VARCHAR Firebird ограничивает максимальный объем памяти хранения любого поля в столбце значениями 32 767 и 32 765 соответственно. На самом деле требуемое фактическое количество может быть сильно ограничено.

Неиндексируемые столбцы, использующие последовательность сортировки по умолчанию, могут хранить не более (количество символов)*(количество байтов на символ) для типа данных. Например, VARCHAR(32765) с набором символов ISO_8859_1 может хранить не более 32 765 символов, тогда как при наборе символов UNICODE_FSS (который использует три байта на символ) максимальное количество 10 291 символ.

Если столбец предполагается индексировать и/или изменить предложением COLLATE, должно быть добавлено значительное количество «запасных» байтов. Даже наименее требовательный индекс — один столбец VARCHAR, использующий однобайтовый набор символов и последовательность сортировки по умолчанию — ограничен размером 252 байта для Firebird версии 1.5 и выше. Для столбцов с многобайтовыми наборами символов количество символов меньше, чем 252 / (количество байтов на символ). Многостолбцовые индексы требуют больше байтов, чем одностолбцовые, а те, которые используют последовательность сортировки не по умолчанию, требуют еще больше.

Более подробно об этих эффектах см. разд. «Последовательность сортировки и размер индекса» далее в этой главе.

! ! !

СОВЕТ. При проектировании столбцов всегда рассматривайте возможные требования с точки зрения использования набора символов, индексирования и ключа. Всегда держите «черновую» таблицу в разрабатываемой базе данных для тестирования ограничений индексов и ключей.

. ! .

Хранение столбцов BLOB, которые не являются индексируемыми, никак не ограничивается использованием набора символов.

Набор символов по умолчанию для базы данных

Если вы не указываете набор символов по умолчанию для базы данных в объявлении CREATE DATABASE, то набор символов по умолчанию устанавливается в NONE. Набор символов NONE не предполагает никакого набора символов для текстовых столбцов, сохраняя данные точно в том виде, в каком они были введены. Если клиентское соединение не указывает набора символов, то данные также будут отыскиваться точно так, как они были введены. Алфавитно-цифровое упорядочение ограничено упорядочением кодов ASCII, а преобразование верхний/нижний регистр поддерживается только в кодах U.S.ASCII 65-90 и 97-102 соответственно.

Указывайте допустимый код набора символов в предложении DEFAULT CHARACTER SET:

CREATE DATABASE ‘/data/adatabase.fdb’

. . .

DEFAULT CHARACTER SET WIN1251;

Более подробную информацию об операторе CREATE DATABASE см. в главе 12.

Переопределение набора символов на уровне столбца

Атрибут набора символов может быть добавлен к индивидуальному определению домена, столбца таблицы или переменной PSQL типа CHAR, VARCHAR или BLOB SUB_TYPE 1 для перекрытия набора символов по умолчанию базы данных.

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

CREATE DATABASE ‘/data/authors.fdb’ DEFAULT CHARACTER SET ISO8859_1;

CREATE TABLE COUNTRY_INTL(

CNTRYCODE BIGINT NOT NULL,

NOM_FR VARCHAR(30) NOT NULL,

/* использует набор символов по умолчанию */

NOM_EN VARCHAR(30), /* использует набор символов по умолчанию */

NOM_RU VARCHAR(30) CHARACTER SET WINI251,

NOM_JP VARCHAR(30) CHARACTER SET SJIS_0208

Другой фрагмент того же скрипта создает домен для хранения данных BLOB В наборе символов кириллицы:

CREATE DOMAIN MEMO_RU AS BLOB SUB_TYPE 1

CHARACTER SET WIN1251;

Позже в этом скрипте мы создаем таблицу, которая хранит некоторый текст в кириллице:

CREATE TABLE NOTES_RU (

DOC_ID BIGINT NOT NOLL,

NOTES MEMO_RU

);

Следующий фрагмент определяет хранимую процедуру, которая преобразует входную строку в другой набор символов перед сохранением ее в таблице:

CREATE PROCEDURE CONVERT_NOTES (

INPUT_TEXT VARCHAR(300) ) AS

DECLARE VARIABLE CONV_STRING WARCHAR(300)

CHARACTER SET WIN1251;

BEGIN

IF (INPUT JTEXT IS NOT NULL) THEN

BEGIN

CONV_STRING = _WIN1251 ‘ ‘ || : INPUT_TEXT;

/* использует INTRODUCER */

INSERT INTO NOTES_RU (DOC_ID, NOTES)

VALUES (GEN_ID (ANYGEN, 1) , :CONV_STRING) ;

END

END ^

Создание доменов объясняется в главе 13. Полный синтаксис оператора CREATE TABLE описан в главе 15. Объявление переменных в PSQL см. в главе 30.

Переопределение набора символов на уровне оператора

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

INTRODUCER — маркер набора символов

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

Установите маркер слева от отмечаемого текстового значения. Например, маркером для ввода в UMCODE_FSS поле является _UNICODE_FSS:

INSERT INTO EMPLOYEE(Emp_ID, Emp_Name)

values(1234, _UNICODE_ESS ‘Smith, John Joseph’);

! ! !

СОВЕТ. Для ясности вы можете вставить пробел между маркером и строкой без какого-либо влияния на способ синтаксического анализа вводимого данного.

. ! .

Строковый литерал

Строковый литерал в условии проверки или поиска, например в предложении WHERE, интерпретируется в соответствии с набором символов клиентского соединения в момент проверки условия. Маркер потребуется, когда отыскиваемый столбец базы данных имеет набор символов, отличный от того, который был указан в клиентском соединении:

… WHERE name = _ISO8859_1 ‘joe’;

! ! !

СОВЕТ. Когда вы разрабатываете приложение со смешанными наборами символов, то удобно использовать маркеры, особенно если ваше приложение будет работать со многими базами данных и/или будет распространяться интернационально.

. ! .

Транслитерация

Преобразование символов из одного набора символов Firebird в другой — например, конвертирование из DOS437 в ISO8859_1 — является транслитерацией. Транслитерация в Firebird сохраняет точность символов: по определению она не подставляет никакого «заменителя» для входного символа, который не представлен в выходном наборе символов. Назначением такого ограничения является гарантия того, что возможна транслитерация одного и того же текста из одного набора символов в другой в любом направлении без потери символов в процессе транслитерации.

Ошибки транслитерации

Firebird выдает сообщение об ошибке, если символ во входном наборе не имеет точного представления в выходном наборе.

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

Исправление ошибок транслитерации

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

Предположим, ваша проблемная таблица имеет столбец COL ORIGINAL, который вы случайно создали с набором символов NONE, когда имели в виду CHARACTER SET WIN1251. Вы загрузили в этот столбец данные на русском языке, но каждый раз, когда вы пытаетесь получить из него данные, вы получаете противную ошибку транслитерации.

Вот что вам нужно сделать:

ALTER TABLE TABLEA

ADD COL_WIN1251 VARCHAR(30) CHARACTER SET WIN1251;

COMMIT;

UPDATE TABLEA

SET COL_WIN1251 = CAST(COL_ORIGINAL AS CHAR(30) CHARACTER SET OCTETS);

Теперь у вас есть временный столбец, созданный для хранения русских текстов, он хранит все из ваших «потерянных» текстов из неиспользуемого столбца COL ORIGINAL. Вы можете удалить столбец COL_ORIGINAL, а затем новый столбец COL_ORIGINAL С корректным набором символов. Просто скопируйте данные из временного столбца, и после подтверждения транзакции удалите временный столбец:

ALTER TABLE TABLEA

DROP COL_ORIGINAL;

COMMIT;

ALTER TABLE TABLEA

ADD COL_ORIGINAL VARCHAR(30) CHARACTER SET WIN1251;

COMMIT;

UPDATE TABLEA

SET СOL_ORIGINAL = COL_WIN1251;

COMMIT;

/* Было бы разумным сейчас посмотреть ваши данные! */

ALTER TABLE TABLEA

DROP COL_WIN1251;

COMMIT;

Набор символов для клиентского соединения

Когда клиентское приложение, например, isql, соединяется с базой данных, в протоколе соединения присутствует часть, которая информирует сервер о требуемом наборе символов. Набором символов соединения является нейтральный набор символов NONE, если не указано другое с использованием:

* SET NAMES во встроенном приложении или в isql;

* параметра isc_dpb_ic_ctype в блоке параметров базы данных (DPB) для API- функции isc_attach_database(). Классы RAD соединения с базой данных для Delphi, Java и других обычно представляют этот параметр как свойство.

Клиентское приложение задает набор символов до его соединения с базой данных. Например, следующая команда isql определяет, что isql использует набор символов ISO88591. По команде происходит соединение с базой данных autord.fdb из нашего предыдущего примера:

SET NAMES WIN1251;

CONNECT ‘lserver:/data/authors.fdb’ USER ‘ALICE’ PASSWORD ‘XINEOHP’;

Специальные наборы символов

Основное правило для наборов символов то, что каждый байт (пара или тройка байтов в случае многобайтовых наборов) специально определен по стандарту его реализации. Существует четыре особых исключения — NONE, OCTETS, ASCII и UNICODE FSS. В табл. 11.1 показаны специальные свойства этих наборов.

Таблица 11.1. Специальные наборы символов

Имя	Свойства
NONE	Каждый байт является частью строки, но не имеется никаких предположений, к какому набору символов он принадлежит. Код клиентской стороны или определенный пользователем на сервере код является ответственным за правильность символа
OCTETS	Байты, которые не интерпретируются как символы. Полезен для хранения двоичных данных
ASCII	Значения 0-127 определены как ASCII. Значения за пределами этого диапазона не являются символами, но поддерживаются. Firebird совершенно либерален относительно транслитерации байтов в диапазоне 0-127 символов ASCII
UNICODE_FSS	Разработчикам нужно знать, что он эффективен при реализации UTF8. Пользователям нужно знать, что он может быть использован для хранения символов UCS16, но не UCS32 (может занимать до шести байтов на символ). Недоступна ни одна последовательность сортировки, кроме двоичной последовательности по умолчанию

ISO8859_1 (LATIN_1) и WIN1252

Набор символов ISO8859_1 часто указывается для поддержки европейских языков. ISO8859_1, также известный как LATIN1, является истинным подмножеством WIN 1252. Microsoft добавил символы в позиции, которые ISO специфицировал как не являются символами (не «неопределенные», но указанные как «не символы»). Firebird поддерживает как WIN 1252, так и ISO8859_1. Вы всегда можете выполнить транслитерацию из ISO8859_1 в WIN 1252, но транслитерация WIN 1252 в ISO8859_1 может вызвать ошибки.

Наборы символов для Microsoft Windows

Пять наборов символов поддерживают приложения клиентов Windows, такие как Paradox for Windows. Это наборы символов WIN1250, WIN1251, WIN1252, WIN1253 и WIN 1254.

Благодаря историческим связям Borland с Paradox и dBase, имена последовательностей сортировки этих наборов символов, специфичных для Paradox for Windows, начинаются с «PXW» и соответствуют языковым драйверам Paradox/dBase, поставляемым с ныне устаревшим Borland Database Engine (BDE).

Понимание наборов символов WINnnn

Последовательности сортировки PXW действительно реализуют сортировку для Paradox и dBase, включая все ошибки. Одно исключение: PXW_CSY исправлен в Firebird 1.0. Следовательно, базы данных InterBase, которые его используют, например в индексах, не являются совместимыми с Firebird.

Более подробную информацию о наборах символов Windows и сортировках Paradox for Windows см. в соответствующей документации по BDE и драйверам.

Список международных наборов символов и последовательностей сортировки, поддерживаемые Firebird, см. в приложении 8.

Последовательности сортировки

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

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

Последовательность сортировки для столбца задается при создании или модификации столбца. Если устанавливается на уровне столбца, то перекрывает любую установку последовательности сортировки на уровне домена.

Отображение доступных последовательностей сортировки

Следующий запрос дает список наборов символов с доступными последовательностями сортировки:

SELECT

С. RDB$CHARACTER_SET_NAME,

CO.RDB$COLLATION_NAME,

CO.RDB$COLLATION_ID,

CO.RDB$CHARACTER_SET_ID,

CO.RDB$COLLATION_ID * 256+ CO.RDB$CHARACTER_SET_ID AS TEXTTYPEID

FROM RDB$COLLATIONS CO

JOIN RDB$CHARACTER_SETS С

ON CO.RDB$CHARACTER_SET_ID = C.RDB$CHARACTER_SET_ID;

Именование последовательностей сортировки

Многие имена последовательностей Firebird используют соглашение по именованию XX_YY, где XX — двухбуквенный код языка, a YY — двухбуквенный код страны. Например, DE_DE — имя последовательности для немецкого языка, используемого в Германии, FR_FR — для французского языка, используемого во Франции, FR_CA — для французского языка, используемого в Канаде.

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

В этом разделе описывается задание последовательности сортировки для наборов символов в доменах и столбцах таблиц, в строковых сравнениях, в предложениях ORDER BY и GROUP BY.

Последовательность сортировки для столбца

Когда в таблице создается столбец CHAR или VARCHAR с использованием CREATE TABLE или ALTER TABLE, последовательность сортировки для столбца может быть задана с использованием предложения COLLATE. Предложение COLLATE особенно полезно для таких наборов символов, как ISO8859_1 и DOS437, которые поддерживают множество различных последовательностей сортировки.

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

ALTER TABLE ‘EMP_CANADIEN’

ADD ADDRESS VARCHAR(40) CHARACTER SET WIN1251 NOT NULL COLLATE PXW_CYRL;

Полный синтаксис ALTER TABLE см. В главе 16.

Последовательность сортировки для строковых сравнений

Может оказаться необходимым задать последовательность сортировки при сравнении значений CHAR или VARCHAR в предложении WHERE, если сравниваемые значения используют различные последовательности сортировки, и это влияет на результат.

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

WHERE SURNAME COLLATE PXW SYRL >= :surname;

В этом случае при несоответствии последовательностей сортировки могут быть различные кандидаты для «больше чем» при разных последовательностях сортировки.

Последовательность сортировки в критериях сортировки

Когда столбцы CHAR или VARCHAR упорядочиваются в операторе SELECT, может оказаться необходимым указать порядок сортировки для упорядочивания, особенно если столбцы в предложении упорядочивания используют различные последовательности сортировки.

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

. . .

ORDER BY SURNAME COLLATE PXW_CYRL, FIRST_NAME COLLATE PXW_CYRL;

Полный синтаксис предложения ORDER BY CM. в главе 23.

Последовательность сортировки в предложении GROUP BY

Когда столбцы CHAR или VARCHAR группируются в операторе SELECT, может оказаться необходимым указать порядок сортировки для группирования, особенно если столбцы в предложении группировки используют различные последовательности сортировки.

Чтобы задать последовательность сортировки для использования в группируемых столбцах, в предложение GROUP BY добавьте COLLATE после имени столбца. Например, в следующем предложении GROUP BY задаются последовательности сортировки для нескольких столбцов:

. . .

GROUP BY ADDR_3 COLLATE PXW_CYRL, SURNAME COLLATE PXW_CYRL, FIRST_NAME COLLATE

PXW_CYRL;

Полный синтаксис предложения GROUP BY CM. В главе 23.

Последовательность сортировки и размер индекса

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

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

* Первый порядок: А отличается от В.

* Второй порядок: А отличается от А.

* Третий порядок: А отличается от а.

* Четвертый порядок: важным является тип знака пунктуации (дефис, пробел, апостроф).

Например:

Greenfly

Green fly

Green-fly

Greensleeves

Green sleeves

Green spot

Если же пробелы и знаки пунктуации трактуются как символы первого порядка, то тот же самый список будет отсортирован следующим образом:

Greenfly

Greensleeves

Green fly

Green sleeves

Green spot

Green-fly

Как недвоичные сортировки могут ограничить размер индекса

Когда создается индекс, он использует последовательности сортировки, определенные для каждого текстового фрагмента индекса. При использовании однобайтового набора символов ISO8859_1 с сортировкой по умолчанию структура индекса может содержать приблизительно 252 символа (меньше, если это многосегментный индекс). Если же вы выбираете недвоичную сортировку для ISO8859_1 (в том числе это относится к сортировке PXW_CYRL кодировки WIN1251), то структура индекса может содержать только 84 символа, несмотря на то, что символы в индексируемом столбце занимают только один байт каждый.

! ! !

ВНИМАНИЕ! Некоторые сортировки ISO8859_1, например DE_DE, требуют в среднем три байта на символ для индексируемого столбца.

. ! .

Пользовательские наборы символов и сортировки

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

Также можно реализовать пользовательские наборы символов и сортировки с использованием функций, определенных пользователем (UDF) для транслитерации входных данных. Сервер Firebird 1.5 автоматически использует UDF со специальными именами, чтобы их можно было распознать как наборы символов и сортировки. Имя ‘USER_CHARSET_nnn’ указывает набор символов, в то время как ‘USER_TRANSLATE_nnn_nnn’ и ‘USER_TEXTTYPE_nnn’ указывает набор символов плюс последовательность сортировки (nnn представляет трехсимвольное число, обычно в диапазоне от 128 до 254).

Это сложная тема, выходящая за пределы данной книги. Разработчик для fbintl2 встраиваемых пользователем наборов символов David Brookestone Schnepper создал свободно распространяемый комплект «сделай сам», который содержит пример кода С, отображения и инструкции, доступный на http://www.ibcoIlate.com. Поскольку комплект поставки содержит ясные инструкции по созданию наборов символов, он также будет вам полезным справочником, если вы планируете использовать подход UDF для реализации пользовательского набора символов.

Добавление собственных алиасов

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

Инсталляция пользовательских алиасов включает прямое добавление строки в таблицу RDB$TYPES. Получите идентификатор набора символов, для которого вы собираетесь создать алиас — в таблице RDB$CHARACTER_SETS это значение столбца RDB$CHARACTER_SET_ID — и убедитесь, что у вас правильный строковый литерал, который ваша операционная система распознает как набор символов, который вы хотите поддерживать.

Предположим, вы хотите добавить алиас для набора символов ISO8859_1, который ваша ОС сможет распознать по литералу ‘LC_ISO88591’. Во-первых, получите идентификатор набора символов по запросу к таблице RDB$CHARACTER_SETS, используя утилиту isql или другой интерактивный инструмент запросов:

SELECT RDB$CHARACTER_SET_ID

FROM RDB$CHARACTER_SETS

WHERE RDB$CHARACTER_SET_NAME = ‘ISO8859_1’;

Этот пример вернет идентификатор набора символов «21». Затем подготовьте и выполните оператор INSERT для добавления вашего алиаса в таблицу RDB$TYPES:

INSERT INTO RDB$TYPES (

RDB$FIELD_NAME, RDB$TYPE, RDB$TYPE_NAME)

VALUES (‘RDB$CHARACTER_SET_NAME’, 21, ‘LC_ISO88591’);

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

Существует проблема типа «уловка-22», если ваша операционная система по- настоящему не может поддерживать набор символов или алиас для набора символов, который вам нужно использовать по умолчанию. Ваша база может «узнать» о вашем алиасе только после создания базы данных, когда таблица RDB$TYPES уже существует. Набор символов базы данных по умолчанию определяется в CREATE DATABASE, а в этот момент доступны только объявленные в системе алиасы. В тот момент, когда RDB$TYPES существует, уже поздно назначать набор символов по умолчанию.

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

UPDATE RDB$DATABASE

SET RDB$CHARACTER_SET_NAME = ‘LC_ISO88591’;

COMMIT;

! ! !

ВНИМАНИЕ! Никогда не пытайтесь выполнить то же для любой базы данных, которая не является «пустой» — т. е. содержит определенные пользователем объекты.

. ! .

Пора дальше

Теперь мы переходим к типам данных, которые Firebird реализует посредством больших двоичных объектов (BLOB), включая текст, нетипизированные двоичные и пользовательские форматы и специализированные реализации BLOB, которые Firebird представляет как типы ARRAY.

ГЛАВА 12. BLOB и массивы.

Типы BLOB (Binary Large Objects, большие двоичные объекты) являются сложными структурами, используемыми для хранения дискретных объектов данных переменного размера, который может быть очень большим. Они являются «сложными» в том смысле, что Firebird сохраняет эти типы в виде двух частей: специальная гиперссылка (называется BLOB ID) сохраняется в собственной строке, в то время как сами данные хранятся за пределами строки, часто на одной или нескольких страницах базы данных, на которые указывает BLOB_ID.

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

Типы BLOB

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

Типы BLOB могут, когда это возможно^[28], хранить содержимое файлов, сгенерированных другими приложениями, такими как текстовые процессоры, программное обеспечение CAD или редакторы XML. Преимущества могут быть в управлении транзакциями для динамических данных, защите от внешнего интерфейса, управлении версиями и возможности доступа к внешне созданным данным с помощью средств операторов SQL.

Столбцы BLOB не могут быть проиндексированны.

Поддерживаемые типы BLOB

Firebird имеет два предварительно определенных типа BLOB, отличающиеся атрибутом подтипа (ключевое слово в SQL SUB_TYPE), как описано в табл. 12.1.

Таблица 12.1. Предварительно определенные подтипы BLOB

Определение	Алиас SQL	Назначение
BLOB SUB_TYPE 0	Не используется	Общий тип BLOB данных любого вида, включая текст. Общее название: «нетипизированный двоичный BLOB», однако Firebird ничего не знает о его содержании
BLOB SUB_TYPE 1	BLOB SUB_TYPE TEXT	Более специализированный подтип для хранения полного текста. Эквивалентен типам CLOB и MEMO, реализованных в некоторых других СУБД. Рекомендуется использовать с интерфейсами приложений, таких как компоненты RAD или поисковые машины, которые выполняют специальную трактовку для каждого типа

Подробнее о подтипах

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

Пользовательские подтипы могут быть добавлены с отличающимися идентификаторами особых типов для объектов данных, таких как HTML, XML или текстовый процессор, картинки JPEG или PNG и т.д. — именно вам делать выбор. Отрицательные номера подтипов (от-1 до -32 768) резервируются для пользовательских подтипов.

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

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

DECLARE FILTER <имя-фильтра>

INPUT_TYPE <подтип> /* идентифицирует тип преобразуемого объекта */

OTPUT_TYPE <подтип> /* идентифицирует тип создаваемого объекта */

ENTRY_POINT ‘<имя-точки-входа>’ /* имя экспортируемой функции */

MODULE_NAME ‘<имя-внешней-библиотеки>’;

/* имя библиотеки BLOB-фильтра */

! ! !

ПРИМЕЧАНИЕ. Написание и использование BLOB-фильтров выходит за пределы тем настоящего руководства. Информацию по этой теме можно найти в базах знаний Firebird.

. ! .

Firebird не проверяет тип или формат данных BLOB. При планировании их хранения вы должны создать такой код вашего приложения, чтобы формат данных был согласован с их подтипом, неважно предварительно определенным или пользовательским.

Сегменты BLOB

Данные BLOB хранятся в различных форматах в обычном столбце данных и вне столбца. Они хранятся в виде сегментов на одной или более страницах базы данных. Сегменты являются дискретными фрагментами неформатированных данных, которые обычно создаются приложением в виде потока и передаются функциям API для пакетирования и передачи по сети по одному блоку за раз непрерывно.

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

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

Примеры синтаксиса

Следующий оператор определяет два столбца BLOB: BLOB1 подтипа 0 (по умолчанию) и BLOB2 подтипа 1 (TEXT, с набором символов по умолчанию):

CREATE TABLE TABLE2

(BLOB1 BLOB, /* SUB_TYPE 0 */

BLOB2 BLOB SUB_TYPE 1);

Следующий оператор определяет домен, являющийся текстовым BLOB для хранения текстов в наборе символов ISO8859_1:

CREATE DOMAIN MEMO

BLOB SUB_TYPE TEXT /*BLOB SUB_TYPE 1 */

CHARACTER SET ISO8859_1;

Фрагмент кода SQL показывает, как объявляется локальная переменная BLOB в модуле PSQL:

CREATE PROCEDURE …

. . .

DECLARE VARIABLE AMEMO BLOB SUB_TYPE 1;

Размер сегмента

Когда в таблице определяется столбец BLOB, определение может включать ожидаемые размеры сегментов, которые будут записываться в столбец. Значение по умолчанию — 80 байт — совершенно случайное. Говорят, что такой размер был выбран, потому что это в точности длина строки текстового дисплея!

Установка размера сегмента не влияет на производительность при обработке BLOB на сервере Firebird: сервер совсем его не использует. Для приложений DSQL — которые пишет большинство людей — вы можете просто игнорировать его или, если это важно, установите его в некоторое значение, подходящее буферу, в котором ваше приложение сохраняет данные BLOB.

Для операций DML, выполняемых через API — SELECT, INSERT и UPDATE — длина сегмента указывается явно и может быть любого размера вплоть до максимума в 32 767 байт. Повторно используемые классы, драйверы и компоненты для таких сред разработки, как Delphi, C++ и Java, обычно сами заботятся о сегментации BLOB в их внутренних функциях и процедурах (например, в IBX и FIBPlus размер сегмента для чтения и записи BLOB равен 16 Кбайт и может быть изменен только глобально).

Встроенные приложения

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

Следующий оператор создает два столбца BLOB: BLOBI С размером сегмента по умолчанию 80 и BLOB2 с заданным размером сегмента 1024:

CREATE.TABLE TABLE2 (BLOBI BLOB SUB_TYPE 0,

BLOB2 BLOB SEGMENT SUB_TYPE TEXT SEGMENT SIZE 1024);

В следующем фрагменте кода ESQL приложение вставляет сегмент BLOB. Длина сегмента указана в переменной включающего языка segment_iength:

INSERT CURSOR BCINS VALUES (:write_segment_buffer :segment_length);

Операции с полями BLOB

Поле BLOB никогда не обновляется. Каждое обновление, которое «изменяет» BLOB, приводит к конструированию нового BLOB, создавая и новый BLOB ID. Первоначальный BLOB становится устаревшим, когда подтверждаются обновления.

Столбец BLOB можно проверять на NULL/NOT NULL, но не существует внутренних функций сравнения одного BLOB С другим или сравнения BLOB со строкой. Некоторые UDF для BLOB, доступные на сайтах сообщества, включают сравнения двух BLOB на равенство.

Невозможно выполнить конкатенацию двух BLOB или BLOB со строкой (без использования сторонних UbF).

Входная строка для столбца BLOB

При получении данных для ввода столбцов BLOB для операций INSERT или UPDATE Firebird может взять строку как исходную и преобразовать ее в BLOB, например:

INSERT INTO ATABLE (PK, ABLOB) VALUES (99, ‘This is some text.’);

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

CREATE PROCEDURE DEMO (INPUTARG BLOB SUB_TYPE I) AS

BEGIN

END ^

COMMIT ^

EXECUTE PROCEDURE DEMO(‘Show us what you can do with this!’)

Вместо этого выполните одно из следующих:

* определите ваш входной аргумент как VARCHAR, и пусть ваша процедура подставляет эту строку в операторы INSERT или UPDATE;

* пусть ваша клиентская программа выполняет конвертирование строки в текст BLOB. Это предпочтительное решение, если длина строки не известна.

Когда использовать типы BLOB

BLOB более предпочтительны, чем символьные типы, для хранения текстовых данных неопределенно большой длины. Поскольку он преобразуется в «бессмысленные фрагменты», к нему не относится ограничение размера строк в 32 Кбайта, пока клиентское приложение реализует подходящие техники передачи его в требуемом сервером формате для его сегментирования^[29].

Поскольку данные BLOB хранятся вне обычной строки данных, они не загружаются автоматически, когда выбрана строка данных. Клиент запрашивает эти данные через BLOB ID. Следовательно, здесь имеется большой «выигрыш» по времени выборки строк с помощью SELECT по сравнению с трафиком, когда используются строковые типы для хранения больших текстовых элементов. С другой стороны, некоторые разработчики могут рассматривать это как недостаток, который требует дополнительной реализации «выборки по требованию».

При принятии решения об использовании BLOB для нетекстовых данных возникает ряд других вопросов. Удобство хранения изображений, звуковых файлов и полных документов должно быть сбалансировано с дополнительными расходами при создании резервных копий базы данных. Может оказаться неразумным стремление хранить большое количество огромных объектов, которые никогда не будут изменяться.

Безопасность

Идея о том, что большие двоичные и текстовые объекты являются более защищенными, когда хранятся в BLOB, чем когда хранятся в файлах файловой системы, является в некоторой мере иллюзией. Конечно, к ним несколько сложнее получить доступ из инструментов конечного пользователя. Однако в настоящий момент привилегии базы данных не применимы к типам BLOB и ARRAY вне контекста таблиц, с которыми они связаны. Не будет абсурдным предположить, что «злобные хакеры», которые получают доступ к файлу базы данных, смогут написать код приложения, который будет сканировать файл в поисках BLOB ID и читать напрямую данные из базы, как это делают внешние функции BLOB.

Типы массивов

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

Типы ARRAY и SQL

Поскольку в Firebird не существует никакого синтаксиса динамического SQL для обработки типов ARRAY, выполнение DML и поиск таких типов

из интерфейсов динамического SQL (DSQL) не является простым делом. API Firebird содержит структуры и функции, позволяющие динамическим приложениям работать с ними напрямую. Некоторые компоненты доступа к данным RAD (например, iBObject, использующиеся в продуктах Borland Delphi и Kylix) содержат классы, инкапсулирующие эту функциональность API в виде свойств и методов клиентской стороны.

ESQL, который не использует структуры и вызовы функций API, поддерживает некоторый статический синтаксис SQL для обработки типов ARRAY и интеграции их с массивами, объявленными во включающем языке.

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

Когда использовать тип массива

Использование массивов является подходящим, когда:

* элементы данных естественно принимают вид множества данных одного типа;

* весь набор элементов данных в одном столбце базы данных должен быть представлен и должен управляться как одно целое вместо того, чтобы сохранять каждый элемент в отдельном столбце;

* к каждому элементу также должен быть индивидуальный доступ;

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

Подходящие типы элементов

Массивы могут содержать элементы любого поддерживаемого Firebird типа за исключением BLOB. Массивы массивов не поддерживаются. Все элементы конкретного массива имеют один и тот же тип данных.

Определение массивов

Массив может быть определен как домен (с использованием CREATE DOMAIN) или как столбец в операторе CREATE TABLE или ALTER TABLE. Определение домена или столбца как массива похоже на определение любого другого такого объекта, здесь только добавляется указание размерности массива. Размерность массива заключается в квадратные скобки и следует за спецификацией типа данных.

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

CREATE TABLE ATABLE (ID BIGINT,

ARR_CHAR(14)[8] CHARACTER SET OCTETS);

/* хранит 1 строку по 8 элементов */

Многомерные массивы

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

CREATE TABLE BTABLE (

/* хранит 4 строки по 5 элементов = 20 элементов */

ARR_INT2 INTEGER[4,5],

/* 6 уровней, по 4 строки по 5 элементов = 120 элементов */

ARR_INT3 INTEGER [4,5,6],

/* 7 ярусов, по 6 уровней в 4 строки по 5 элементов = 840 элементов */

ARR_INT6 INTEGER[4,5,6,7] ) ;

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

Задание диапазона значений индексов для размерностей

Размерности массивов в Firebird задаются в виде верхней и нижней границ, называемых списком индексов. По умолчанию размерности основаны на 1 — первый элемент массива из n элементов имеет индекс 1, второй элемент имеет индекс 2, а последний элемент индекс n. Например, следующий оператор создает таблицу со столбцом, который является массивом четырех целых:

CREATE TABLE TABLEC (ARR_INT INTEGER[4]);

Индексы этого массива 1, 2, 3 и 4.

Пользовательские (явные) границы индексов

Пользовательская установка верхней и нижней границы может быть явно определена для каждой размерности массива при создании столбца ARRAY. Например, программисты С и Pascal, знакомые с массивами, основанными на нуле, могут создавать столбцы массивов с нулевой нижней границей для полного соответствия со структурой массивов в коде приложения.

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

[ нижняя:верхняя]

Следующий пример создает таблицу с одноразмерным, основанным на нуле столбцом массива:

CREATE TABLE TABLED

(ARR_INT INTEGER[0:3]);

/* индексы 0, 1, 2, и 3. */

Каждое задание границ размерности отделяется от следующего запятой. Например, следующий оператор создает таблицу со столбцом массива размерности два, где обе размерности основаны на нуле:

CREATE TABLE TABLEE

(ARR_INT INTEGER[0:3, 0:3]);

Хранение столбцов массивов

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

Обновления

Как и в случае других типов BLOB, сервер Firebird не может последовательно просматривать индивидуальные элементы при условном обновлении. При этом в одиночном операторе DML возможно изолировать один элемент или набор последовательных элементов, называемый фрагментом, и передавать этот фрагмент для обновления.

Добавления

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

Доступ к данным массива

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

Дескриптор массива

API предоставляет структуру дескриптора массива для передачи серверу массива или фрагмента массива для чтения и записи в базу данных. Эта структура для программистов представлена в файле ibase.h (добавлены комментарии):

typedef struct {

short array_bound_lower;

/* нижняя граница массива или фрагмента */

short array_bound_upper;

/* верхняя граница массива или фрагмента */

} | SC_ARRAY_BOUND;

typedef struct {

unsigned char array_desc_dtype;

/* тип данных элементов */

char array_desc_scale;

/* масштаб для числовых типов */

unsigned short array_desc_length;

/* длина элемента массива в байтах */

char array_desc_field_name[32] ;

/* идентификатор столбца */

char array_desc_relation_name[32];

/* идентификатор таблицы */

short array_desc_dimensions;

/* количество размерностей */

short array_desc_flags;

/* 0=порядок по строкам, 1=порядок по столбцам */

ISC_ARRAY_BOUND array_desc_bounds[16];

/* верхняя и нижняя границы для размерности до 16 */

} ISC_ARRAY_DE SC;

Документ по InterBase 6 «API Guide» (Руководство no API), опубликованный Borland, содержит детальные инструкции по манипулированию массивами с помощью структур API.

Ограничения доступа динамического SQL

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

create procedure getcharslice(

low_elem smallint, high_elem smallint)

returns (id integer, list varchar(50))

declare variable i smallint;

declare variable string varchar(10);

begin

for select a1.ID from ARRAYS a1 into :id do

begin

i= low_elem;

list = » ;

while (i <= high_elem) do

begin

select a2.CHARARRAY[:i] from arrays a2

where a2.ID = :id

into : string;

list = list||string;

if (i < high_elem) then

list = list ||’,’;

i = i + 1;

end

suspend;

end

Пора дальше

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

ГЛАВА 13. Домены.

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

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

Как было отмечено, домены не могут быть подставлены вместо типов данных при определении аргументов и переменных в хранимых процедурах и триггерах.

! ! !

ПРИМЕЧАНИЕ. Замещение атрибутов домена на уровне столбца обсуждается позже в этой главе.

. ! .

Столбцы, основанные на определении домена, наследуют все атрибуты домена, которые могут быть:

* типом данных (обязательно);

* значением по умолчанию для INSERT;

* состоянием NULL;

* ограничениями CHECK;

* набором символов (только для символьных и BLOB столбцов);

* порядком сортировки (только для символьных столбцов).

! ! !

ПРИМЕЧАНИЕ. Вы не можете использовать ограничения ссылочной целостности данных в домене.

. ! .

Преимущества инкапсуляции определения данных очевидны. Для простого, но общего примера предположим, что вы проектируете обращения к множеству малых таблиц, где вы собираетесь хранить текстовые описания пронумерованных множеств — таблицы «типов» — типы счетов, типы продуктов, типы пожертвований и т.д. Вы принимаете решение, что каждый элемент каждого из этих множеств будет иметь ключ, состоящий из трех символов в верхнем регистре, который указывает на символьное описание или поле заголовка, имеющее максимум 25 символов.

Все это требует создания двух доменов.

* Домен для указателя будет CHAR(3) с двумя дополнительными атрибутами: ограничение NOT NULL, поскольку вы собираетесь его использовать в качестве первичного ключа и ключа поиска, и ограничение CHECK для проверки наличия прописных букв. Например:

CREATE DOMAIN Туре_Кеу AS CHAR(3) NOT NULL

CHECK(VALUE = UPPER(VALUE));

* Домен описания будет VARCHAR(25). Вы хотите запретить для него пустые значения, поскольку таблицы, в которых вы собираетесь его использовать, являются управляющими:

CREATE DOMAIN Type_Description AS VARCHAR(25) NOT NULL;

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

Создание домена

Синтаксис языка определения данных (DDL) для создания домена:

CREATE DOMAIN домен [AS] <тип-данных>

[DEFAULT литерам |NULL |USER]

[NOT NULL] [CHECK (<условие-поиска-домена>)]

[CHARSET набор-символов| NONE]

[COLLATE порядок-сортировки];

Идентификатор домена

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

CREATE DOMAIN D_TYPE_IDENTIFIER…

CREATE DOMAIN DESCRIPTION_D. . .

Тип данных домена

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

Следующий оператор создает домен, определяющий массив символьного типа:

CREATE DOMAIN DEPTARRAY AS CHAR(31) [4:5];

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

CREATE DOMAIN DESCRIPT_JP AS BLOB SUB_TYPE TEXT

CHARACTER SET SJIS;

Атрибут DEFAULT

Домен может определять значение по умолчанию, которое сервер будет использовать при добавлении новой строки, если оператор INSERT не содержит этот столбец в списке столбцов. Значения по умолчанию могут сэкономить время и избавить от ошибок в процессе ввода данных. Например, для столбца DATE возможным значением по умолчанию может быть текущая дата, а для столбца userName (имя пользователя) можно указать контекстную переменную CURRENT_USER.

Значение по умолчанию может быть:

* константой. Значением по умолчанию является заданная пользователем строка, числовое значение или значение даты — часто используется для помещения «нулевого значения» в столбец, куда не могут помещаться пустые значения (NULL);

* CURRENT_TIMESTAMP, CURRENT_DATE, CURRENT_TIME или предварительно определенный литерал даты Firebird (см. главу 10);

* USER, CURRENT_USER или CURRENT_ROLE (если применяются роли);

* CURRENT_CONNECTION или CURRENT_TRANSACTION.

! ! !

ПРИМЕЧАНИЕ. Возможно указание в качестве значения по умолчанию NULL. Хотя это излишне, поскольку столбцы, допускающие пустое значение, в любом случае инициализируются по умолчанию значением NULL. Более того, явное указание значения по умолчанию NULL может привести к конфликтам, если столбец, использующий домен, должен быть определен с ограничением NOT NULL (CM. разд. «Атрибут NOT NULL» далее в этой главе).

. ! .

Следующий оператор создает домен, который должен иметь положительное значение больше 1000. Если в операторе INSERT не указан столбец, созданный на основе этого домена, столбцу будет назначено значение по умолчанию 9999:

CREATE DOMAIN CUSTNO

AS INTEGER

DEFAULT 9999

CHECK(VALUE > 1000);

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

Когда значения по умолчанию не работают

Распространенная ошибка предполагать, что значение по умолчанию будет использовано, когда Firebird получает значение NULL в столбце, имеющем значение по умолчанию. Чтобы быть уверенным в правильном использовании значений по умолчанию, нужно понимать, что значение по умолчанию будет применено:

* только при добавлении новой строки;

* только если оператор INSERT не включает столбец со значением по умолчанию в списке столбцов.

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

Атрибут NOT NULL

Включите этот атрибут в описание домена, если вы хотите, чтобы все столбцы, создаваемые на основе этого домена, имели непустое значение.

NULL — который является не значением, а состоянием, — всегда будет недопустимым для любого столбца, имеющего атрибут NOT NULL. Детальное обсуждение NULL см. в разд. «Рассмотрение NULL» главы 21.

! ! !

ВНИМАНИЕ! Вы не можете переопределить атрибут NOT NULL для домена. Рассмотрите преимущества невключения его в состав атрибутов домена, оставляя, таким образом, возможность добавить этот атрибут при определении столбца.

. ! .

Условия CHECK

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

Вот синтаксис ограничений CHECK:

<условие-поиска-домена> =

VALUE <оператор> <val>

| VALUE [NOT] BETWEEN <val> AND <val>

| VALUE [NOT] LIKE <val> [ESCAPE <val>]

| VALUE [NOT] IN (<val> [, <val> …])

| VALUE IS [NOT] NULL

| VALUE [NOT] CONTAINING <val>

| VALUE [NOT] STARTING [WITH] <val>

I(<условие-поиска-домена>)

I NOT<условие-поиска-домена>

<условие-поиска-домена> OR <условие-поиска-домена>

| <условие-поиска-домена> AND <условие-поиска-домена>

<оператор> ={=|<|>I<=|>=|!<|!>|<>|!=}

Ключевое слово VALUE

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

Если значение NULL допустимо, то правило должно учитывать этот факт в ограничении CHECK, например:

CHECK ((VALUE IS NULL) OR(VALUE > 1000));

Следующий оператор создает домен, который запрещает вводить значение 1000 и меньше, при этом он также неявно запрещает NULL во множестве допустимых значений:

CREATE DOMAIN CUSTNO

AS INTEGER

CHECK(VALUE > 1000);

Следующий оператор ограничивает VALUE одним из четырех заданных значений:

CREATE DOMAIN PRODTYPE

AS VARCHAR(8) NOT NULL

CHECK(VALUE IN (‘software’, ‘hardware’, ‘other’, ‘N/A’));

Условие проверки может быть выполнено в виде поиска указанного шаблона во вводимой строке. Например, следующее правило проверяет наличие круглых скобок в коде региона (например, (09)438894749):

CREATE DOMAIN TEL_NUMBER

AS VARCHAR (18)

CHECK(VALUE LIKE ‘(0%)%’);

Подробнее о строковых шаблонах, которые вы можете использовать в выражениях, см. в примечаниях к оператору LIKE в разд. «Операторы SQL» главы 21.

Множество условий CHECK

Домен может иметь только одно предложение CHECK, однако множество условий может быть включено в это предложение с помощью операторов AND (И — конъюнкция) и OR (ИЛИ — дизъюнкция). Позаботьтесь о необходимых скобках в выражениях условий, чтобы исключить получение логических исключений при подготовке оператора DDL.

Например, следующий оператор будет ошибочным:

create domain rhubarb as varchar(20)

check(VALUE is not null) and(VALUE starting with ‘J’);

Он вызовет исключение с сообщением «token unknown» на слове «and». Правильный оператор заключает весь список условий во внешние скобки:

create domain rhubarb as varchar(20)

check ((value is not null) and(VALUE starting with ‘J’));

! ! !

ПРИМЕЧАНИЕ. Предыдущий оператор проверяет, чтобы входное значение не было NULL. Это замечательно, однако использование ограничения NOT NULL напрямую является более мощным средством для интерфейса приложения. API может информировать клиентское приложение во время подготовки (prepare) об ограничении NOT NULL, В ТО время как триггеры проверки CHECK не будут вызываться, пока запрос DML не будет фактически отправлен на сервер.

. ! .

Подробности о STARTING WITH и других используемых в выражениях операторах SQL см. в главе 21.

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

Зависимости в ограничениях CHECK

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

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

create domain rather_silly as char(3)

check(VALUE in (select substring(registration from 1 for 3)

from aircraft));

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

Как подход к проектированию баз данных, это плохо объединяется с возможностями обеспечения ссылочной целостности данных, полностью реализованными в Firebird.

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

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

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

! ! !

СОВЕТ. Другим пониманием данной техники является сложность (или невозможность) для вспомогательных программ извлекать непробиваемые бомбами скрипты SQL из системных таблиц. Может наступить такое время, когда ваша работа усложнится из-за необходимости правильного извлечения скриптов SQL из базы данных!

. ! .

Если вам совершенно необходимо использовать этот вид условий проверки, обратитесь к дополнительным условиям при объявлении столбца. Лучше оцените все альтернативы- включая ручное кодирование ссылочных триггеров в случаях, когда внешние ключи для ссылочных полей приведут к проблемам избирательности (селективности) индексов^[30].

Атрибут CHARSET/CHARACTER SET

Для систем, которым нужно множество наборов символов внутри одной базы данных, объявление доменов, связанных с наборами символов для всех ваших символьных столбцов (CHAR, VARCHAR SUB_TYPE 1 и массивов символьных типов), может быть очень элегантным способом работы. Синтаксис определения набора символов можно посмотреть в предыдущей главе.

Атрибут COLLATE

Предложение COLLATE в операторе создания домена задает явную последовательность сортировки для доменов CHAR и VARCHAR. Вы должны выбрать порядок сортировки, который поддерживается набором символов, объявленным наследуемыми и предполагаемым для домена.

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

Использование доменов в определении столбца

Пример

В некоторой базе данных есть домен SYSUSER, размером до 31 символа, имеющий значение по умолчанию, получаемое из контекстной переменной CURRENT_USER:

CREATE DOMAIN SYSUSER AS VARCHAR(31) DEFAULT CURRENT_USER;

Объявляемая таблица содержит столбец UPDATED_BY, который использует домен

SYSUSER:

CREATE TABLE LOANS (

LOAN_DATE DATE,

UPDATED_BY SYSUSER,

LOAN_FEE DECIMAL(15,2));

Клиент содержит оператор INSERT для таблицы LOANS:

INSERT INTO LOANS (LOAN_DATE, LOAN_FEE)

VALUES (116-MAY-20041, 10.75);

Поскольку этот оператор не содержит столбец UPDATED BY в списке столбцов, Firebird автоматически задает имя текущего пользователя ALICEFBIRD:

SELECT * FROM LOANS;

вернет

16-MAY-2004 ALICEFBIRD 10.75

! ! !

ПРИМЕЧАНИЕ. Здесь уместно напомнить, что значения по умолчанию для домена и столбца применяются только при добавлении и только если столбец, имеющий значение по умолчанию, отсутствует во входном списке оператора INSERT. Триггеры имеют более надежные способы реализации значений по умолчанию. Техники обсуждаются в главе 31.

. ! .

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

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

Таблица 13.1. Переопределение атрибутов доменов и столбцов

Атрибут	Переопределяется?	Замечания
Тип данных	Нет
DEFAULT	Да
CHARACTER SET	Да	Также может использоваться, чтобы восстановить для столбца значения по умолчанию базы данных
COLLATE	Да
CHECK	Нет	Используйте предложение CHECK в операторе CREATE или ALTER TABLE для добавления в проверку новых условий
NOT NULL	Нет	Атрибут NOT NULL на уровне домена не может быть переопределен на уровне столбца. Во многих случаях лучше оставить для домена возможность пустого значения и добавлять ограничение NOT NULL для столбцов, где это необходимо, в операторе CREATE или ALTER TABLE

Следующий оператор демонстрирует, как расширяется список атрибутов столбца, основанного на домене, созданного в одном из предыдущих примеров:

CREATE DOMAIN TEL_NUMBER

AS VARCHAR(18)

CHECK(VALUE LIKE ‘(0%)%’);

Скажем, мы хотим определить таблицу, содержащую столбец с номером телефона. Нам нужны атрибуты домена, но нам также необходимо обеспечить, чтобы нецифровые символы вводились в верхнем регистре:

CREATE TABLE LIBRARY_USER (

USER_ID INTEGER NOT NULL.

. . . <другие столбцы>,

PHONE_NO TEL_NUMBER,

CONSTRAINT CHK_TELNUM_UPPER

CHECK (PHONE_NO = UPPER(PHONE_NO))

);

Теперь у нас есть дополнительная проверка CHECK для этого столбца. Следующий оператор:

INSERT INTO LIBRARY_USER VALUES (USER_ID, PHONE_NO)

VALUES (99, ‘(09) 43889 wish’);

будет ошибочным, потому что дополнительное ограничение CHECK требует, чтобы телефонный номер был ‘(09) 43889 wish’.

Когда домены не работают

Домен не может быть использован:

* в функции CAST (<имя_домена> AS <другой_тип>);

* вместо явного типа данных при определении входных и выходных аргументов хранимых процедур;

* при объявлении типа данных локальной переменной в триггере или хранимой процедуре;

* при определении типа данных элементов массива. При этом сам домен может быть массивом.

Объявление домена BOOLEAN

Firebird не поддерживает тип данных BOOLEAN. Домены в стиле BOOLEAN являются идеалом, потому что вы можете объявлять атрибуты, которые будут постоянными для всех таблиц. Рекомендуется использование минимальных типов данных: CHAR для переключателя T[rue]/F[aise] или Y[es]/N[о] или SMALLINT для пары 1/0. Следующие примеры предлагают способы, которыми вы можете реализовать ваши типы BOOLEAN.

Пример 13.1. Двухфазный переключатель со значением по умолчанию ‘F’ (False)

CREATE DOMAIN D_BOOLEAN AS CHAR

DEFAULT ‘F’ NOT NULL

CHECK(VALUE IN (‘T’, ‘F’));

Пример 13.2. Трехфазный переключатель, допускающий значение UNKNOWN (т. е. NULL):

CREATE DOMAIN D_LOGICAL AS SMALLINT

CHECK(VALUE IS NULL OR VALUE IN (1,0));

Пример 13.3. Трехфазный переключатель, представляющий UNKNOWN как значение:

CREATE DOMAIN D_GENDER AS CHAR(4)

DEFAULT ‘N/K’ NOT NULL

CHECK (VALUE IN (‘FEM’, ‘MASC’, ‘N/K’));

! ! !

ВНИМАНИЕ! He используйте BOOLEAN, UNKNOWN, TRUE или FALSE В качестве имен для булевых доменов. В Firebird это зарезервированные слова. Истинно логические типы планируются в Firebird 2 и могут появиться в промежуточных релизах между 1.5 и 2.

. ! .

Изменение определения домена

Оператор языка определения данных ALTER DOMAIN может быть использован для изменения любого аспекта существующего домена за исключением установки NOT NULL. Изменения, сделанные вами в определении домена, воздействуют на все определения столбцов, основанных на этом домене, если только соответствующие атрибуты не были переопределены на уровне таблицы.

Домен может быть изменен его создателем, пользователем SYSDBA или (в Linux/UNIX) любым пользователем с привилегией root операционной системы.

Используя ALTER DOMAIN, вы можете:

* переименовать домен;

* изменить тип данных;

* удалить существующее значение по умолчанию;

* установить новое значение по умолчанию;

* удалить существующее ограничение CHECK;

* добавить новое ограничение CHECK.

! ! !

ПРИМЕЧАНИЕ. Существует только один путь «изменить» установку NOT NULL для домена — это удалить домен и заново создать его с желаемой комбинацией характеристик.

. ! .

Вот синтаксис оператора:

ALTER DOMAIN { имя | старое-имя ТО новое-имя } {

[SET DEFAULT {литерал | NULL | USER | etc.}]

| [DROP DEFAULT]

| [ADD [CONSTRAINT] CHECK (<условия-соответствия>)]

| [DROP CONSTRAINT]

| TYPE тип-данных

};

Примеры

Этот оператор устанавливает новое значение по умолчанию для домена BOOK_GROUP:

ALTER DOMAIN BOOK_GROUP SET DEFAULT -1;

В следующем операторе имя домена BOOK_GROUP заменяется на PUBL_GROUP:

ALTER DOMAIN BOOK_GROUP TO PUBL_GROUP;

Ограничения на изменение типов данных

Предложение TYPE в ALTER DOMAIN позволяет заменить тип данных на другой разрешенный тип данных. Разрешенные типы преобразований см. на рис. 8.1.

Недопустим никакой тип преобразования, который может привести к потере данных. Например, количество символов в домене не может быть сделано меньше размера наибольшего значения в любом столбце, использующим этот домен^[31].

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

Следующий оператор меняет тип данных домена BOOK_TITLE С CHAR(80) на VARCHAR(100) :

ALTER DOMAIN BOOK_TITLE TYPE VARCHAR(100);

Удаление домена

Оператор DROP DOMAIN удаляет из базы данных существующее описание домена при условии, что домен не используется в каком-либо описании столбца базы данных.

Чтобы не получить исключений, применяйте ALTER TABLE для удаления всех столбцов, использующих домен, а затем выполняйте DROP DOMAIN. Лучший способ сделать это за одно задание — использовать скрипт DDL. См. разд. «Скрипты схемы» в следующей главе.

Домен может быть удален его создателем, пользователем SYSDBA или (в Linux/UNIX) любым пользователем с привилегией root операционной системы.

Вот синтаксис оператора:

DROP DOMAIN name;

Следующий оператор удаляет ненужный домен:

DROP DOMAIN rather_silly;

Пора дальше

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

Глава 14 начнется с изложения базовых правил разработки моделей в реляционных базах данных. Глава закончится разделом о работе со скриптами БД.

ЧАСТЬ IV. База данных и ее объекты.

ГЛАВА 14. Чертежная доска для базы данных.

Конечно же, база данных хранит данные. Однако данные сами по себе не могут использоваться, если они не были сохранены в соответствии с некоторыми правилами, которые, во-первых, определяют их смысл и значение и, во-вторых, позволяют их отыскивать соответствующим образом. База данных, существующая в контексте системы управления базами данных (СУБД), такой как Firebird, включает в себя множество «вещей» помимо данных.

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

Пользователь SYSDBA и пароль

Во всех версиях Firebird, включая 1.5, пользователь SYSDBA имеет полные права ко всем базам данных на сервере. Инсталляционные скрипты устанавливают базу данных безопасности с паролем по умолчанию masterkey.

Некоторые релизы 1.5 для Linux запускают скрипт, который генерирует новый пароль для пользователя SYSDBA. Вы можете посмотреть сгенерированный пароль в файле SYSDBA.password в корневом каталоге Firebird.

! ! !

ВНИМАНИЕ! Пароль masterkey широко известен. Убедитесь, что вы изменили его на малопонятную восьмисимвольную строку. См. инструкции в главе 34.

. ! .

Метаданные

Все вместе объекты, определенные в базе данных, называются метаданными или, более традиционно, ее схемой. Процесс создания и модификации метаданных называется определением данных. Термин «определение данных» также часто применяется к описанию одного объекта и его атрибутов.

В этом разделе в деталях рассматриваются концепции, терминология и язык определения данных.

Язык определения данных

Основные структуры базы данных — ее таблицы, просмотры и индексы — создаются с использованием подмножества языка SQL Firebird, известного как язык определения данных (Data Definition Language, DDL). Оператор DDL начинается с одного из ключевых слов CREATE, ALTER, RECREATE или DROP, которые означают создание, изменение, пересоздание или удаление одного объекта, соответственно. База данных, ее объекты, правила и отношения объединяются для формирования структуры реляционной базы данных.

Системные таблицы

Firebird хранит метаданные в множестве таблиц, которые он создает прямо в базе данных, — в системных таблицах. Идентификаторы всех системных таблиц начинаются с символов «RDB$». Например, таблица, которая хранит определения и другую информацию о структурах всех таблиц в вашей базе данных, называется RDB$RELATIONS. Связанная с ней таблица RDB$RELATION_FIELDS хранит информацию и описания всех столбцов в каждой таблице.

Такая «база данных в базе данных» является высоко нормализованной. Операторы DDL разработаны для выполнения безопасных операций с таблицами метаданных и в полном соответствии с каскадными эффектами.

Возможно изменение данных в системных таблицах посредством обычных операций SQL. Некоторые инструменты администратора, такие как isql и gfix, выполняют внутренние изменения данных в системных таблицах. При этом, будучи сложной системой управления базами данных, Firebird не была разработана в предположении, что конечный пользователь будет манипулировать строками системных таблиц.

! ! !

ВНИМАНИЕ! Не рекомендуется пренебрегать операторами DDL и самостоятельно изменять системные таблицы с помощью кода приложений или через интерактивные инструменты. Системные таблицы являются «мета-метаданными» любой базы данных. Любое вмешательство человека, скорее всего, приведет к непредсказуемым повреждениям.

. ! .

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

Проектирование базы данных

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

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

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

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

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

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

* Изолирует систему от ошибок проектирования в последующих циклах разработки.

Описание и анализ

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

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

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

Эта фаза может быть одной из наиболее сложных задач для проектировщика базы данных, особенно в окружении, где> бизнес был приспособлен к работе с электронными таблицами и настольными базами данных. Прискорбно, что даже в среде клиент-сервер можно найти слишком много медленно работающих, подверженных разрушению баз данных, которые были «спроектированы» с использованием отчетов и электронных таблиц в качестве своей основы^[32].

Модель данных <> база данных

Тот «мир», который был получен в процессе описания и анализа, является черновиком для структур ваших данных. Считается, что логическая модель должна описывать отношения и наборы. Обычная ошибка (и западня, присущая всем инструментам CASE) слепо транслировать модель данных в схему базы данных. В сложных системах управления базами данных, таких как Firebird, структура таблицы не всегда представляет оптимальный объект, из которого должны отыскиваться данные. Запросы, просмотры, массивы, вычисляемые столбцы и хранимые процедуры выбора являются лишь небольшой частью доступных механизмов поиска и хранения, которые будут влиять на вашу реализацию модели при физическом проектировании.

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

Одна база данных или много?

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

При проектировании принимайте во внимание, что Firebird не поддерживает запросы, соединяющие или объединяющие таблицы из различных баз данных. При этом он поддерживает одновременные запросы к множеству баз данных в контексте одной транзакции и при двухфазном ее подтверждении. Таким образом, приложения могут выполнять задачи, которые работают с образами данных из двух и более баз данных и выполняют операторы DML к одной базе данных, используя данные, прочитанные из другой. Подробности о транзакциях с несколькими базами данных и о двухфазном подтверждении см. в главе 27.

Физические объекты

Таблицы

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

! ! !

СОВЕТ. Firebird поддерживает техники реализации ссылающихся на себя таблиц — структура строк, которая задает зависимости между строками в той же таблице. Подробности см. в разд. «Ссылающиеся на себя отношения» главы 17.

. ! .

Файлы и страницы

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

В рамках файла сервер Firebird управляет блоками диска одного размера, называемыми страницами базы данных. Он управляет некоторыми различными «типами» страниц в соответствии с хранимыми типами данных — например, обычные столбцы таблицы, BLOB, индексы. Когда требуется, сервер размещает новый блок в файловой системе хоста. Все страницы независимо от типа имеют одинаковый размер. Размер страницы должен быть указан в операторе CREATE DATABASE. Он может быть изменен только при выполнении резервного копирования и восстановления базы данных с новым размером страницы при использовании утилиты gbak.

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

Столбцы и поля

Обобщенно, столбец является совокупностью атрибутов, определяющих элемент данных, который может быть сохранен в одной указанной ячейке в структуре строки таблицы слева направо. При этом столбцы фактически не существуют в таблицах базы данных. Каждый раз, когда запрос обращается к серверу, этот запрос задает набор столбцов и одну или более операций, выполняемых над этими столбцами. Столбцы не обязательно должны располагаться в том же порядке слева направо, как они были определены в таблице. Например, оператор SELECT FIELD3, FIELD1, FIELD2 FROM ATABLE;

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

Некоторые люди используют термин «поле» вместо столбца, например: «У меня есть таблица TABLEI, содержащая три поля». Часто книги по реляционным базам данных не одобряют использование «поле» как замена для «столбец», предпочитая использовать «поле» в смысле «значение в столбце» или «ссылка на столбец».

В этой книге «поле» используется только как термин для обобщения

концепции столбца, аргумента и локальной переменной и для ссылок на выходные элементы, создаваемые во время выполнения. «Столбец» используется для ссылок на физические столбцы, определенные для таблиц.

Ключи

Первичный ключ

Основной частью процесса проектирования базы данных является выделение в логической модели базы данных для каждой таблицы одного уникального столбца или структуры из нескольких столбцов, которая отличает каждую строку от любой другой строки в таблице. Такой уникальный столбец или комбинация столбцов является логическим первичным ключом (primary key). Когда вы создаете вашу физическую модель, вы используете ограничение PRIMARY KEY, чтобы сообщить СУБД, какой столбец или столбцы формируют такую уникальную идентификационную структуру. На таблицу вы можете определить только одно ограничение PRIMARY KEY. Синтаксис рассматривается в разд. «Ограничения» главы 16.

Другие уникальные ключи

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

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

«Кабелями», которые делают реляционную базу данных «реляционной», являются внешние ключи (foreign key). Это столбец или структура столбцов, которая в вашей модели данных является стороной «многие» в отношении один-ко-многим. При физическом проектировании внешний ключ соответствует столбцу или структуре столбцов первичного ключа таблицы стороны «один» в этом отношении.

В следующей простой модели для примера детальные строки заказа связаны с заголовком заказа через ключ ORDER_NUMBER.

Рис. 14.1. Простая связь

Такая модель требует, чтобы каждая строка заголовка имела уникальный ORDER_NUMBER и существовала, по меньшей мере, одна детальная строка заказа для каждой заголовочной строки заказа. Другие правила могут применяться к факту существования и к связи. Firebird предоставляет мощные процедуры триггеров для установки, согласования и применения правил к отношениям. Дополнительно он может автоматизировать множество типичных правил управления отношениями, включая ограничение FOREIGN KEY С дополнительными аргументами действий. Основой для такого ограничения являются сгенерированные системой триггеры ссылочной целостности. Поддержка ссылочной целостности в Firebird вкратце обсуждалась ранее в разд. «Ссылочная целостность» и будет детально рассмотрена в главе 17.

Суррогатные ключи

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

CREATE TABLE PERSON {

FIRST_NAME VARCHAR(30) NOT NULL,

LAST NAME VARCHAR(50) NOT NULL,

PHONE_NUMBER VARCHAR(18) NOT NULL,

ADDRESS_1 VARCHAR(50),

. . . );

Проектировщик принимает решение, что комбинация (FIRST_NAME, LAST_NAME, PHONE NUMBER) является хорошим кандидатом для первичного ключа. Люди могут использовать один и тот же телефонный номер, но весьма маловероятно, что два человека с одинаковыми именем и фамилией будут использовать один и тот же номер телефона, верно? Таким образом, проектировщик делает следующее:

ALTER TABLE PERSON

ADD CONSTRAINT PK_PERSON PRIMARY KEY

(LAST_NAME, FIRST_NAME, PHONE_NUMBER) ;

Первая проблема с этим первичным ключом в том, что каждый элемент имеет смысл. Каждый элемент поддерживается человеком и может быть изменен или записан с ошибками. Два ключа (‘Smith’, ‘Mary’, ‘43889474’) и (‘SMITH’, ‘Mary’, ‘43889474’) Не являются одинаковыми и оба могут быть помещены в эту таблицу. Какая запись будет изменена, если магу выйдет замуж или изменит номер телефона?

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

Реальные накладки могут появиться, если эти столбцы используют многобайтовые наборы символов или не двоичные порядки сортировки. Размеры индексов ограничены 252 байтами. Для ключей обязательно создаются индексы. Такой ключ будет невозможен просто по причине слишком большого размера.

Создание атомарного ключа

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

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

Общую технику реализации автоинкрементного первичного ключа (при отсутствии ручной работы) см. в разд. «Генераторы» главы 9 ив главе 31.

! ! !

ВНИМАНИЕ! Атомарность ключа должна поддерживаться в приложениях сокрытием его от пользователя или хотя бы его свойством только для чтения.

. ! .

Итог — суррогатные ключи против естественных ключей

Разработчики баз данных обычно занимают четкую позицию «за» или «против» использования суррогатных ключей. Позиция автора по использованию атомарности очевидна. Несмотря на это, в интересах справедливости аргументы за и против представлены в табл. 14.1.

Таблица 14.1. Суррогатные (искусственные) ключи в сравнении с естественными

Особенность	За	Против
Атомарность	Суррогатные ключи не воспринимаются как данные и никогда не изменяются	Естественные ключи по своей сути нестабильны, потому что они являются предметом человеческих ошибок и внешних изменений
Удобство	Естественные ключи несут информацию, сокращающую необходимость выполнения соединений или дополнительных чтений для поиска данных в контексте. Естественные ключи более удобны при использовании в интерактивных инструментах запросов	Суррогатные ключи не несут никакой информации помимо их функции связи, требования соединений или подзапросов поиска связанных «осмысленных» данных
Размер ключа	Суррогатные ключи компактны	Естественные ключи имеют больший размер и часто усложняют составные ключи, которые усложняют запросы и схему
Навигация	Суррогатные ключи обеспечивают чистую, быструю навигацию по коду	Естественные ключи обычно не являются подходящими при навигации в стиле кода по причине порядка сортировки, денормализации и размера
Нормализация	Суррогатные ключи могут быть нормализованы в базе данных	Естественные ключи имеют тенденцию к усложнению, распространению денормализации данных внешних ключей

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

! ! !

ВНИМАНИЕ! При проектировании ключей для базы данных Firebird помните, что ключи порождают индексы, а индексы в Firebird ограничены в размере до 252 байт. Сложные последовательности сортировки и многобайтовые международные наборы символов уменьшают количество символов в данных, которые могут быть использованы в качестве индексов.

. ! .

Ключи не являются индексами

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

* Ключи являются ограничениями.

* Индексы требуются для поддержания ограничений.

! ! !

ВНИМАНИЕ! Вы не должны создавать свои собственные индексы, которые дублируют создаваемые системой индексы для поддержания ограничений. Это является важной мерой предосторожности в отношении производительности, о чем неоднократно повторяется в разных местах книги. Разд. «Темы оптимизации» главы 18 объясняет, почему дублирование таких индексов может ухудшить производительность запросов.

. ! .

Ссылочная целостность данных

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

Синтаксис ограничений формальной ссылочной целостности данных Firebird подробно обсуждается в главе 17.

Индексы и планы запросов

Если внешние ключи являются «кабелями», делающими базу данных реляционной, то индексы могут рассматриваться как поставщики «полосы частот». Хорошее индексирование повышает скорость; отсутствие индексов или плохие индексы замедляют поиск, соединение и сортировку.

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

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

Firebird использует алгоритмы оптимизации, которые в большой мере основаны на оценке затрат (cost-based). При подготовке запроса оптимизатор вычисляет относительные стоимости использования или игнорирования доступных индексов и возвращает клиенту план запроса, сообщая о своем выборе. Хотя можно разработать и передать оптимизатору ваш собственный план запроса- важное средство серверов реляционных СУБД, которые используют оптимизацию, основанную на правилах, — чаще всего оптимизатор Firebird знает лучше. Планы Firebird являются более полезными в выявлении и устранении проблем с индексами.

Проектирование и создание индексов рассматривается в главе 18.

Просмотры

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

Просмотры и другие наследуемые таблицы обсуждаются в главе 24 и должны изучаться вместе с другими главами части V.

Хранимые процедуры и триггеры

Хранимые процедуры и триггеры являются модулями компилированных, выполняемых кодов, которые выполняются на сервере. Исходный код пишется на расширении языка SQL, называемом процедурным SQL, или PSQL.

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

Триггеры являются специализированным видом модулей PSQL, которые могут быть объявлены для выполнения в одном или более из шести состояний/фаз операции (до и после добавления, изменения и удаления) в процессе операций манипулирования данными (DML) таблицы, которая владеет этими триггерами. Группы триггеров могут быть объявлены для каждой фазы для выполнения в определенной последовательности. Начиная с релиза 1.5, поведение любой или всех операций DML могут быть объединены с условиями выполнения в один модуль триггера «до» или «после». Триггеры не принимают входных аргументов и не возвращают выходных наборов.

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

PSQL имеет механизмы обработки исключений и внешних событий. Любое количество сообщений об исключениях может быть определено в качестве объектов базы данных с использованием операторов CREATE EXCEPTION. Внешние события создаются внутри модуля PSQL, а приложения могут устанавливать структуры для их «прослушивания».

Подробное обсуждение написания и использования модулей PSQL, исключений и событий см. в части VII.

Соглашения по именованию объектов базы данных и ограничения

Должны соблюдаться ограничения в именовании объектов базы данных.

* Начинайте каждое имя с буквенного символа (A-Z или a-z).

* Ограничивайте имена объектов 31 символом. Некоторые объекты, например имена ограничений, могут иметь длину до 27 символов.

* Допустимые символы для имен файлов базы данных — как и для всех объектов метаданных в Firebird — включают знаки доллара ($), подчеркивания (_), цифры от 0 до 9, буквы от А до Z и от а до z.

* Обеспечьте требования уникальности в базе данных:

• во всех случаях имена объектов одного типа — например, таблиц — должны быть уникальными;

• имена столбцов в таблице должны быть уникальными в этой таблице. Все другие идентификаторы объектов должны быть уникальными в базе данных.

* Исключите использование зарезервированных слов, пробелов, диакритических знаков и любых символов ASCII с кодом больше 127:

• в диалекте 1 они вообще не могут быть использованы;

• в диалекте 3 вы можете ограничить «неправильные» идентификаторы, используя пару символов двойной кавычки. Подробности будут дальше.

Идентификаторы с разделителями SQL-92

В базах данных диалекта 3 Firebird поддерживает соглашение ANSI SQL об идентификаторах с разделителями. Для использования зарезервированных слов, диакритических знаков, чувствительных к регистру строк или пробелов в имени объекта заключите имя в двойные кавычки. Теперь оно становится идентификатором с разделителями. Идентификаторы с разделителями должны всегда быть представлены с двойными кавычками.

! ! !

ПРИМЕЧАНИЕ. В диалекте 1 зарезервированные слова, диакритические знаки и пробелы недопустимы в именах объектов; идентификаторы, чувствительные к регистру, не поддерживаются.

. ! .

Имена, заключенные в двойные кавычки, являются чувствительными к регистру. Например,

SELECT «CodAR» FROM «MyTable»

отличается от

SELECT «CODAR» FROM «MYTABLE»

Заключать в кавычки или нет

Соглашение по двойным кавычкам для идентификаторов объектов было введено для совместимости со стандартами. Для тех, кто привык в прошлом в InterBase к нечувствительности к регистру, новая «возможность» будет в лучшем случае сбивать с толку, в худшем — раздражать.

Если вы определяете объекты в двойных кавычках, вы должны везде и всегда использовать их в двойных кавычках и обеспечивать соответствие регистра. Большинство опытных разработчиков Firebird рекомендует отказаться от них за исключением редких случаев, когда вам нужно использовать «неправильные» идентификаторы. Выбор за вами.

Исключение соответствия регистру

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

! ! !

СОВЕТ. Большинство графических инструментов базы данных Firebird предоставляет режим автоматического применения заключенных в кавычки идентификаторов. Один или два из этих инструментов фактически применяют идентификаторы в кавычках для всех объектов базы данных по умолчанию. Если у вас нет серьезных оснований использовать это, рекомендуется найти «отключающий переключатель» и отменить идентификаторы в кавычках.

. ! .

Соглашения по именованию файлов базы данных

Установленное соглашение по именованию файлов баз данных Firebird для любой платформы — использование трехсимвольного суффикса fdb для первичного файла, а для имен вторичных файлов f01, f02 и т.д. Это только соглашение — файлы Firebird могут иметь любое расширение или не иметь расширения вовсе.

По причине известных проблем с серверами XP, использующими SystemRestore для файлов с расширением gdb, разработчикам рекомендуется заменить традиционный суффикс файлов InterBase при миграции баз данных в Firebird.

Имя базы данных безопасности- security.fdb в релизе 1.5 и выше, isc4.gdb в релизе 1.0.x- не должно изменяться. К сожалению, у Firebird 1.0.x нет средств изменения требуемого суффикса gdb.

Скрипты схемы

В Firebird, как и во всех других системах управления базами данных SQL, вы создаете вашу базу данных и ее объекты (метаданные или схема базы данных), используя операторы из специализированного подмножества операторов SQL, называемого языком определения данных (Data Definition Language, DDL). Пакет операторов DDL в текстовом файле называется скриптом. Скрипт или множество скриптов могут быть обработаны программой isql непосредственно из командной строки или при помощи инструмента, предоставляющего дружественный интерфейс.

Список таких инструментов см. в приложении 5.

Скрипты Firebird

Скрипт для создания и изменения объектов базы данных иногда называют файлом определения данных или скриптом DDL. Скрипт DDL может содержать определенного рода операторы isql, а также некоторые из команд SET <параметр>. COMMIT также является допустимым оператором в скрипте.

! ! !

ПРИМЕЧАНИЕ. Утилита isql (интерактивный SQL) является программой командной строки, доступной на всех платформах; входит в состав комплекта поставки Firebird. Во всех случаях, кроме встроенного сервера для Windows, isql инсталлируется в каталог /bin корневого каталога Firebird. Полные инструкции см. в главе 37.

. ! .

Другие скрипты могут быть написаны для добавления основных, или «управляющих», данных в таблицы, изменения столбцов, преобразования данных и выполнения других задач, включающих манипулирование данными. Такие скрипты называются скриптами DML (для языка манипулирования данными, Data Manipulation Language).

Команды DDL и DML могут одновременно присутствовать в скриптах. Однако для устранения проблем с целостностью данных строго рекомендуется размещать операторы DDL и DML в отдельных скриптах. Обработка скриптов позволяет «изменять» скрипты, связывая один файл скрипта с другим с помощью оператора isql INPUT <спецификация_файла>.

Операторы скрипта выполняются в строгом порядке. Использование команды SET AUTODDL позволяет управлять подтверждением операторов или блоков операторов. Эта команда также позволяет откладывать подтверждение содержимого скрипта, пока не будет выполнен весь скрипт.

Зачем использовать скрипты?

Очень хорошей практикой является использование скриптов DDL для создания вашей базы данных и ее объектов. Перечислим несколько причин для этого.

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

* Управление разработкой базы данных. Представление всех описаний базы данных в скриптах позволяет создание схемы тесно интегрировать с циклами проектирования задач и пересмотра кода.

* Повторяемое и отслеживаемое создание метаданных. Полностью восстанавливаемая схема является требованием гарантированного восстановления системы после сбоев во многих организациях.

* Аккуратное конструирование и реконструирование метаданных базы данных. Опытные программисты Firebird часто создают набор скриптов DDL, разработанных для выполнения и подтверждения в нужном порядке. Это упрощает отладку и гарантирует, что объекты будут существовать, когда позже зависимые объекты будут на них ссылаться.

Что находится в скриптах DDL?

Операторы SQL

Скрипт DDL содержит один или более операторов SQL (CREATE, ALTER, DROP) для создания, изменения или удаления базы данных или любого другого объекта. Он может включать операторы DML, хотя рекомендуется использовать операторы DDL и DML в разных скриптах.

! ! !

СОВЕТ. Довольно общей является практика включения (INPUT) В цепочку скриптов DDL одного или более скриптов, содержащих операторы INSERT для ввода в некоторые таблицы статичных управляющих данных. Вы можете, например, включить операторы для добавления начальных строк в таблицу учетных записей. Убедитесь, что все операторы DDL подтверждаются до появления других операторов DML.

. ! .

Операторы процедурного языка (PSQL), определенные для хранимых процедур и триггеров, также могут быть включены в скрипты. Блоки PSQL получают специальную трактовку в скриптах в зависимости от символов терминатора операторов (см. далее разд. «Символы терминатора»).

Блок комментариев

Блок комментариев в скриптах DDL использует соглашения языка С:

/* Этот комментарий распространяется на множество строк в скрипте */

Блок комментариев может появиться в той же строке, что и оператор SQL или команда isql, и может быть произвольной длины. Он начинается символами /* и заканчивается символами */.

Линейные комментарии

Комментарий стиля /*…*/ также может быть встроен внутрь оператора как линейный комментарий:

CREATE TABLE USERS1 (

USER_NAME VARCHAR( 128 )

/* security user name */

, GROUP_NAME VARCHAR(128)

/* not used on Windows */

, PASSWD VARCHAR( 32 )

/* will be stored encrypted */

, FIRST_NAME VARCHAR(96) /* Defaulted */

, MIDDLE_NAME VARCHAR( 96 ) /* Defaulted */

, LAST_NAME VARCHAR( 96 ) /* Defaulted */

, EULL_NAME VARCHAR( 290 ) /* Computed */

) ;

Однострочные комментарии

В скриптах Firebird вы можете использовать альтернативное соглашение по комментированию одной строки — двойной минус:

— комментарий

В релизе 1.0.x этот стиль комментария не может быть использован для линейного комментария или для «закомментирования» части строки.

В релизе 1.5 и выше соглашение по комментированию — может быть использовано в любом месте строки для «комментирования» всего, начиная с маркера до конца текущей строки, например:

CREATE TABLE MET_REPORT (

ID BIGINT NOT NULL, — VARCHAR(40), невидим

WEATHER_CONDITIONS

BLOB SUB_TYPE TEXT,

LAST_REPORT TIMESTAMP) ;

Операторы isql

Команды isql SET AUTODDL, SET SQL DIALECT, SET TERM и INPUT являются допустимыми операторами в скриптах Firebird — подробности об этих командах см. в главе 37.

Символы терминатора

Все операторы, которые выполняются в скрипте, должны оканчиваться символом терминатора. Символ по умолчанию — точка с запятой (;).

Символ терминатора по умолчанию может быть изменен для всех операторов за исключением операторов языка процедур (PSQL) при использовании в скрипте команды SET TERM^[33].

Терминаторы и язык процедур (PSQL)

PSQL не допускает никаких терминаторов за исключением точки с запятой (;). Такое ограничение необходимо, потому что CREATE PROCEDURE, RECREATE PROCEDURE, ALTER PROCEDURE, CREATE TRIGGER и ALTER TRIGGER вместе с их операторами PSQL являются сложными операторами с их собственными правилами. Компилятору нужно видеть точку с запятой для различения каждого оператора PSQL.

Следовательно, в скриптах необходимо переопределять используемый в командах скрипта терминатор перед началом операторов PSQL для хранимых процедур и триггеров. После последнего оператора END, когда завершается исходный текст процедуры, следует восстановить значение терминатора по умолчанию, используя другой оператор SET TERM. Пример:

CREATE GENERATOR GEN_MY_GEN ;

SET TERM ^^;

CREATE TRIGGER BI_TABLEA_0 FOR TABLEA

ACTIVE BEFORE INSERT POSITION 0

BEGIN

IF (NEW.PK IS NOT NULL) THEN

NEW.PK = GEN_ID(GEN_MY_GEH, 1);

END ^^

SET TERM ; ^^

. . .

Любая строка может быть использована в качестве альтернативного терминатора, например:

SET TERM @ ! #;

CREATE PROCEDURE…

BEGIN

. . . ;

END @!#

SET TERM ;@!#

/**/

COMMIT;

/**/

SET TERM +;

CREATE PROCEDURE…

BEGIN

. . .;

. . . ;

END +

SET TERM ; +

/**/

COMMIT;

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

Например, в следующей последовательности оператор COMMIT не будет выполняться:

ALTER TABLE ATABLE ADD F2 INTEGER; COMMIT;

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

ALTER TABLE ATABLE ADD F2 INTEGER; /* счетчик бобов */

COMMIT;

Основные шаги

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

Шаг 1: создание файла скрипта

Используйте любой подходящий текстовый редактор. На стадии обучения вы можете за каждым оператором DDL записывать оператор COMMIT, чтобы обеспечить видимость объекта последующим операторам. Когда вы получите больше опыта, вы научитесь подтверждать операторы в блоках, применяя SET AUTODDL ON и SET AUTODDL OFF с целью управления взаимозависимостями и при тестировании/отладке скриптов.

! ! !

ВНИМАНИЕ! Убедитесь, что каждый скрипт заканчивается символом перевода строки и, по меньшей мере, одной пустой строкой.

. ! .

Шаг 2: выполнение скрипта

Используйте команду INPUT в сессии isql, или кнопку Выполнить (Execute), или аналогичную в вашем инструменте управления базой данных.

isql в POSIX:

SQL> INPUT /data/scripts/myscript.sql;

isql в Win32:

SQL> INPUT d:datascriptsmyscript.sql;

Шаг 3: просмотр результата и подтверждение изменений базы данных

Разные инструменты Firebird и версии isql возвращают различную информацию в случае ошибочного выполнения скрипта при наличии неверной команды. Средства,

добавленные после Firebird 1.0, обеспечивают более подробные сообщения об ошибках скрипта, чем предыдущие версии.

Как создавать скрипты

Вы можете создавать скрипты DDL различными способами, включая следующие:

* в сессии интерактивной isql с использованием команды OOTPOT для передачи серий операторов DDL в файл;

* в текстовом редакторе ASCII, который выполняет переводы строки в соответствии с правилами командной строки операционной системы, где будет выполняться скрипт DDL;

* используя специализированные инструменты редактора скриптов, которые доступны среди инструментов администратора для Firebird сторонних разработчиков. См. список в приложении 5;

* используя инструмент CASE, который может выводить скрипты DDL в соответствии с соглашениями Firebird (InterBase).

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

* в Windows терминатор строки — символ возврата каретки плюс символ перевода строки (ASCII 13, за которым следует ASCII 10);

* в Linux/UNIX терминатор строки — символ перевода строки, или «новая строка» (ASCII 10);

* в Mac OS X терминатор строки- новая строка (ASCII 10), а в родных Macintosh это возврат каретки (ASCII 13).

! ! !

СОВЕТ. См. также в isql возможность извлечения метаданных, которая может быть полезной для извлечения схемы БД в формате скрипта.

. ! .

Некоторые инструменты редактирования имеют возможность сохранять данные в различных текстовых форматах. Это может быть полезным, например, при создании скриптов, совместимых с Linux, на машине Windows. При этом убедитесь, что вы используете редактор, который сохраняет только полный текст ASCII.

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

! ! !

ПРИМЕЧАНИЕ. Не используйте алиасы в скриптах, которые создают базы данных.

. ! .

Пример:

SET SQL DIALECT 3 ;

CREATE DATABASE ‘d:databasesMyDatabase.fdb’ PAGE_SIZE 8192

DEFAULT CHARACTER SET ISO8859_1 USER ‘SYSDBA’ PASSWORD ‘masterkey’;

или

CONNECT ‘d:databasesMyDatabase.gdb’ USER ‘SYSDBA’ PASSWORD ‘masterkey’;

Подтверждение операторов в скрипте

Операторы DDL

Операторы в скриптах DDL могут подтверждаться одним или несколькими способами:

* включением в соответствующих местах скрипта операторов COMMIT, чтобы гарантировать доступность новых объектов базы данных всем последующим зависящим от них операторам;

* включением в начало скрипта следующего оператора:

SET AUTODDL ON;

Для отмены автоматического подтверждения операторов DDL в скрипте isql используйте:

SET AUTODDL OFF;

Ключевые слова ON и OFF необязательны. Сокращение SET AUTO может быть использовано в качестве двухстороннего переключателя. Для большей ясности рекомендуется использовать SET AUTODDL с явным указанием ключевых слов ON и OFF.

Автоматическое подтверждение isql

Если вы выполняете свой скрипт в isql, то изменения базы данных операторами определения данных (DDL)- например, операторами CREATE и ALTER- автоматически подтверждаются по умолчанию. Это означает, что другие пользователи базы данных видят изменения сразу после выполнения оператора DDL.

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

Операторы DML

Изменения базы данных, выполненные операторами манипулирования данными (DML) — INSERT, UPDATE и DELETE, — не станут постоянными, пока не будут подтверждены. Явно включите операторы COMMIT в ваш скрипт для подтверждения изменений DML.

Для отмены всех изменений базы данных после последнего COMMIT используйте ROLLBACK. Подтвержденные изменения не могут быть отменены.

Выполнение скриптов

Скрипты DDL могут быть выполнены в сессии интерактивного isql с использованием команды INPUT, как было описано ранее. Многие инструменты сторонних разработчиков позволяют выполнять и даже интеллектуально отлаживать скрипты в среде графического интерфейса.

Управление скриптами вашей схемы

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

Восстановление после сбоев

Наиболее очевидная цель такой практики — «возврат к последней точке» при восстановлении после сбоев. Если беда идет за бедой — база данных разрушена, а резервные копии потеряны — метаданные можно восстановить из скриптов. Сохранившиеся данные из другой невосстанавливаемой базы данных могут быть восстановлены специалистами и помещены в базу данных.

Управление разработкой

Скорее всего, несколько разработчиков будут создавать базу данных в течение ее жизненного цикла. Известно, что разработчики ненавидят написание системной документации! Хранение аннотированных записей скриптов о каждом изменении базы данных- включая те, которые использовались интерактивно через isql или инструмент сторонних разработчиков, — это безболезненное и безопасное решение, которое работает во всех случаях.

Извлечение метаданных

Некоторые инструменты администратора для Firebird, включая isql, могут выделять метаданные из базы данных и сохранять их в виде файла скрипта. Об использовании isql см. разд. «Извлечение метаданных» главы 37. Так как извлечение метаданных является удобным помощником в вашем использовании скриптов, существует множество причин трактовать эти инструменты как «ассистенты» и взять себе за правило вручную поддерживать ваши главные скрипты схемы.

* Firebird не хранит комментарии при сохранении определений метаданных. Многие системные таблицы имеют столбец BLOB, обычно называемый RDB$DESCRIPTION, в котором может сохраняться в виде единого целого часть предоставленного пользователем описания. При извлечении метаданных инструментом isql этот столбец не выводится, хотя некоторые инструменты сторонних разработчиков его поддерживают.

* Все инструменты извлечения метаданных генерируют только текущие метаданные. Не существует истории изменений — даты, причины или авторы изменений.

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

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

Создание скриптов вручную

Автор жестко пропагандирует поддержку полностью аннотированных скриптов схемы вручную и разделение их на несколько отдельных файлов. Пример набора скриптов в табл. 14.2 описывает и регенерирует базу данных с именем leisurestore.fdb.

Таблица 14.2. Пример набора скриптов для схемы

Файл	Содержимое
leisurestore_01 .sql	Оператор CREATE DATABASE; определения CREATE DOMAIN, CREATE GENERATOR и CREATE EXCEPTION
leisurestore_02.sqi	Все операторы CREATE TABLE, включая ограничения UNIQUE; операторы ALTER TABLE добавляют все первичные ключи в виде именованных ограничений PRIMARY KEY
leisurestore_03.sql	Операторы ALTER TABLE, добавляющие ограничения FOREIGN KEY
leisurestore_04.sql	Операторы CREATE INDEX
leisurestore_05.sql	Операторы CREATE TRIGGER
leisurestore_06.sql	Операторы CREATE PROCEDURE
leisurestore_07.sql	Скрипт операторов DML, который добавляет строки в статичные (управляющие) таблицы
leisurestore_08.sql	Операторы GRANT (скрипт безопасности)
leisurestore_09.sql	Более поздние изменения в корректной последовательности зависимостей
leisurestore_10.sql	Скрипты QA (тестовые данные)

Цепочки скриптов

Устойчивый набор скриптов может быть соединен вместе в цепочку с использованием оператора isql INPUT В качестве последнего оператора в предыдущем скрипте. Например, для присоединения скрипта leisurestore_0.sql к leisurestore_01.sql завершите скрипт следующим образом:

. . .

COMMIT;

— присоединение к операторам CREATE TABLE

INPUT ‘d:scriptsleisurestore_02.sql’ ;

— не забудьте добавить пустую строку!

Подход, основанный на главном скрипте

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

Пора дальше

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

ГЛАВА 15. Создание и ведение базы данных.

База данных Firebird — это, прежде всего, файл файловой системы, находящийся под управлением подсистемы ввода/вывода главной машины, на которой выполняется сервер Firebird. Как только сервер создаст этот файл, его система управления начинает управлять его пространством, используя протокол низкого уровня для связи с подсистемой ввода/вывода.

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

Новая, «пустая» база данных занимает на диске около 540-600 Кбайт. Файл базы данных вовсе не является пустым, поскольку «акт создания» — оператор CREATE DATABASE- приводит к созданию более 30 системных таблиц. Эти таблицы будут хранить каждую деталь метаданных, как только объект базы данных будет добавлен или изменен. Так как системные таблицы являются обычными объектами базы данных Firebird, они уже содержат для себя записи метаданных. Сервер уже выделил страницы базы данных на диске для этих данных и создал инвентарные страницы для различных типов объектов.

Обсуждение страниц базы данных см. в предыдущей главе.

Физическое хранение базы данных

Размещение

До создания базы данных вы должны знать, где собираетесь ее создавать. Это не столь глупо, как звучит. Оператор CREATE DATABASE (альтернатива- CREATE SCHEMA) будет создавать файл или файлы с указанными вами именами, однако он не может создать каталоги и не может изменить полномочия доступа файловой системы. Этим деталям следует уделить внимание в первую очередь.

Дополнительно сервер Firebird 1.5 может быть сконфигурирован для ограничения размещения баз данных. Проверьте параметр DatabaseAccess в файле firebird.conf (см. главу 3), чтобы выяснить, где ваш сервер ограничен в доступе. Если у вас установки по умолчанию (Full), то вы можете создавать базу данных в любом месте. Иначе:

* установка Restrict указывает файловой системе иерархию, в которой разрешен доступ к базе данных. Убедитесь, что пользователь, запускающий ваш сервер, имеет достаточные полномочия для создания там файла (или, в случае встроенного сервера Windows, подключающийся пользователь);

* установка None позволяет серверу соединяться только с базами данных, находящимися в списке в aliases.conf. Вы можете создавать базу данных в любом месте, однако, за исключением создания, никакой клиент не будет иметь возможности соединиться с ней, если алиас БД и ее абсолютный адрес не будут присутствовать в aliases.conf.

! ! !

ВНИМАНИЕ! Настоятельно рекомендуется устанавливать режим DatabaseAccess в NONE и использовать средства алиасов базы данных. Более подробную информацию об алиасах базы данных см. в разд. «Алиасы базы данных» главы 4.

. ! .

Безопасность доступа

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

Если база данных еще не существует, и вы запустили из командной строки isql без параметров, то произойдут две вещи:

* вы соединяетесь с сервером;

* пока вы не отправите на сервер запрос CONNECT или CREATE DATABASE, программа не будет соединена с базой данных.

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

Вопросы доступа к серверу и безопасности базы данных подробно обсуждаются в части VIII.

ISC_USER и ISC_PASSWORD

На сервере можно установить две переменные окружения: ISC_USER и ISC_PASSWORD, чтобы избежать необходимости явно записывать пароли в скриптах. Вы можете делать все, что разрешено указанному пользователю. Эта возможность удобна для административных задач, однако она должна быть использована с большой осторожностью, потому что оставляет доступ к вашей базе данных открытым для любого локального пользователя, кто случайно натолкнется на ваше окно командной строки.

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

В Linux в том же окне командной строки, из которого вы запускали приложение, введите:

]# setenv ISC_USER=SYSDBA

]# setenv ISC_PASSWORD=masterkey

Для отмены установок используйте следующее:

]# setenv ISC_USER=

]# setenv ISC_PASSWORD=

или просто закройте окно.

В Windows

в командной строке введите:

set ISC_USER=SYSDBA

set ISC_PASSWORD=masterkey

Для отмены введите:

set ISC_USER=

set ISC_PASSWORD=

Создание базы данных

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

В любом случае более предпочтительным является использование файла определения данных (скрипта DDL), потому что он предоставляет простой способ «проиграть снова» ваши операторы при ошибочном выполнении скрипта. Проще запустить исходный файл, чем заново вводить интерактивные операторы SQL.

Диалект

По умолчанию Firebird создает базу данных диалекта 3. Если вы хотите создать базу данных диалекта 1, первым оператором в вашем скрипте (или первым действием в вашем инструменте администратора) должен быть:

SET SQL DIALECT 1;

! ! !

ВНИМАНИЕ! Если isql в настоящий момент соединен с базой данных, он предложит вам подтвердить текущую транзакцию. Ответьте Yes (Да) для продолжения создания новой базы данных. Некоторые инструменты сторонних разработчиков вначале могут потребовать, чтобы вы отсоединились от базы данных.

. ! .

Следующий оператор — или первый для базы данных диалекта 3 — должен быть оператором CREATE DATABASE или CREATE SCHEMA такого синтаксиса^[34]:

CREATE {DATABASE | SCHEMA} ‘спецификация-файла ‘

[USER ‘имя-пользователя’ [PASSWORD ‘пароль’]]

[PAGE_SIZE [=] целое]

[LENGTH [=] целое [PAGE[S]]]

[DEFAULT CHARACTER SET набор-символов]

[<вторичный-файл>] ;

<информация-о-файле> = LENGTH [=] целое [PAGE[S]]

STARTING [AT [PAGE]] целое [<информация-о-файле>]

<вторичный-файл> = FILE ‘спецификация-файла’ [<информация-о-файле>]

[<вторичный-файл> ]

! ! !

СОВЕТ. Используйте одиночные кавычки (апострофы) для таких строк, как имена файлов, имена пользователей и пароли.

. ! .

DATABASE или SCHEMA?

CREATE DATABASE и CREATE SCHEMA являются одним и тем же оператором. Это только вопрос ваших предпочтений.

Обязательные и необязательные атрибуты

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

Имя и путь к базе данных

Спецификация файла должна быть полным абсолютным путем к файлу. Путь должен иметь правильный формат в операционной системе.

Для POSIX:

CREATE DATABASE ‘/opt/databases/mydatabase.fdb’

Для Win32:

CREATE SCHEMA ‘d:databasesmydatabase.fdb’

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

Апострофы в спецификации файла являются обязательными. Все элементы спецификации файла чувствительны к регистру для платформ POSIX.

Создание удаленной базы данных

При создании базы данных с клиентской рабочей станции или локально в Суперсервере для Linux — интерактивно или с использованием скрипта — вы должны включить имя хоста.

Для POSIX:

CREATE DATABASE ‘rayserver:/opt/databases/mydatabase.fdb’

Для локального Linux Суперсервера- как и в предыдущем случае или так:

CREATE DATABASE ‘localhost:/opt/databases/mydatabase.fdb’

Для Win32:

CREATE SCHEMA ‘NTServer:d:databasesmydatabase.fdb’

Владение базой данных

Если вы подключены как пользователь SYSDBA, то SYSDBA будет владеть новой базой данных, независимо от того, как были заданы предложения USER и PASSWORD. Хотя указание владельца не является обязательным, очень желательно это сделать. При этом по причине безопасности вы, вероятно, захотите удалить из скрипта пароль пользователя перед архивацией скрипта с остальной системной документацией.

CREATE DATABASE ‘/opt/databases/mydatabase.fdb’

USER ‘ADMINUSR’ PASSWORD ‘yyuryyub’;

Размер страницы

Необязательный атрибут PAGE_SIZE (размер страницы) задается в байтах. Если вы его опустите, будет принято значение по умолчанию: 4096 байт в isql. Некоторые другие инструменты применяют свое значение по умолчанию, значит, есть веский аргумент указывать это значение в скрипте явно. Размер страницы может быть 1024, 2048, 4096, 8192 или 16 384. Любые другие значения будут преобразованы в ближайшее меньшее число из этого списка. Например, если вы укажете 3072, Firebird создаст базу данных с размером страницы 2048.

CREATE DATABASE ‘/opt/databases/mydatabase.fdh’ USER ‘ADMINUSR’

PASSWORD ‘yyuryyub’

PAGE_SIZE 8192

Факторы, влияющие на выбор размера страницы

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

Выбранный вами размер страницы может улучшить производительность или плохо на нее воздействовать в зависимости от множества факторов, главным образом, от структуры и порядка использования таблиц, к которым чаще всего осуществляется доступ. Каждая страница базы данных будет заполняться приблизительно на 80 процентов, следовательно, рассуждайте в терминах реального размера страниц, который должен составлять около 125 процентов от предполагаемого минимума.

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

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

Набор символов по умолчанию

Строго рекомендуется, чтобы все — или почти все — ваши текстовые данные были в кодировке U.S. ANSII^[35].

CREATE DATABASE ‘/opt/databases/mydatabase.fdb’

USER ‘ADMINUSR’ PASSWORD ‘yyuryyub’

PAGE_SIZE 8192

DEFAULT CHARACTER SET ISO8859_1;

Подробнее о наборах символов см. в главе 11. Доступные наборы символов представлены в приложении 8.

Получение информации о базе данных

После того как вы создали базу данных и подтвердили создание (commit), вы можете в isql отобразить ее детали, используя команду SHOW DATABASE:

SQL> SHOW DATABASE;

Database: /opt/databases/mydatabase.fdb

Owner: ADMINUSR

PAGE_SIZE 8192

Number of DB pages allocated = 176

Sweep interval = 20000

Forced Writes are ON

Transaction — oldest = 5

Transaction — oldest active = 6

Transaction — oldest snapshot = 6

Transaction — Next = 9

Default character set: ISO8859_1

SQL>

Интервал очистки и транзакции

Информацию о чистке базы данных и интервале очистки см. в разд. «Гигиена базы данных» далее в этой главе.

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

Принудительная запись

Принудительная запись (forced writes) является синонимом синхронной записи. На платформах, которые поддерживают асинхронную запись, базы данных Firebird создаются по умолчанию с принудительной записью. Фраза «отключение принудительной записи» означает переключение поведения при записи с синхронного на асинхронное.

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

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

! ! !

ПРИМЕЧАНИЕ. Платформа Windows 95 не поддерживает асинхронную запись.

. ! .

Обсуждение отключения принудительной записи и инструкции по ее установке при использовании gfix см. в главе 39.

Базы данных из одного и нескольких файлов

Любая база данных Firebird может состоять из нескольких файлов. Вначале вам не нужно принимать решения о количестве файлов. База данных из одного файла может

быть преобразована в многофайловую в любое время при использовании ALTER DATABASE (обсуждается в этой главе) или инструмента gbak (см. главу 38).

Задание размера файла для однофайловой базы данных

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

CREATE DATABASE ‘/opt/databases/mydatabase.fdb’

USER ‘ADMINUSR’ PASSWORD ‘yyuryyub’

PAGE_SIZE 8192

LENGTH 10000 PAGES

/* ключевое слово PAGES необязательно */

DEFAULT CHARACTER SET WIN1251;

Если база данных растет до размера большего, чем указанный размер файла, то Firebird расширяет первичный файл за пределы LENGTH, пока не будет достигнут предел, существующий для файловой системы, или не будет исчерпано дисковое пространство. Чтобы не допустить этого, вы можете хранить базу данных более чем в одном файле; дополнительные файлы называются вторичными файлами. Файлы могут размещаться на нескольких дисках.

Создание многофайловой базы данных

Многофайловые базы данных являются результатом старых файловых систем, где абсолютный предел размера файла 2 Гбайта (FAT32, ext2) или 4 Гбайта (система NTFS с 32-битовым вводом/выводом). Они используются для решения общей проблемы пользователей при разрушении базы данных InterBase в случае превышения лимита, когда сервер начинает перезаписывать данные файла с самого начала. Такая же проблема появляется, когда база данных исчерпает размер вторичного файла. Firebird просто отказывается осуществлять запись, когда последний файл достигнет лимита. Следовательно, разрушение существующих данных здесь предотвращено, хотя последующие записи данных будут потеряны.

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

CREATE DATABASE ‘LOCALHOST:/data/sample.fdb’

PAGE_SIZE 8192

DEFAULT CHARACTER SET WIN1251

LENGTH 250000 PAGES

FILE ‘/data/sample.fdl’

FILE ‘/data/sample.fd2’

STARTING AT 250001;

Вы должны указать диапазон страниц для каждого файла либо задав количество страниц в каждом файле, либо указав начальный номер страницы для файла. Для последнего файла вам не нужно указывать размер, поскольку Firebird динамически устанавливает размер последнего файла и будет увеличивать его, пока не будет исчерпано дисковое пространство или пока он не достигнет лимита файловой системы.

В этом примере первый вторичный файл «начнет работать», когда первичный файл приблизится к размеру 2 Гбайта. «Следующий файл в цепочке» начинает применяться, когда запрашиваемой операции понадобится использовать больше страниц, чем могут предоставить предыдущие файлы без превышения заданных им лимитов^[36].

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

При использовании многофайловых баз данных вы можете снять ограничение размера базы данных одним дисковым устройством, если файловая система не обеспечивает размещение одного, очень большого файла на нескольких дисках. Не будет никаких проблем инсталлировать RAID-массив и распространять базу данных Firebird на нескольких дисках для любой поддерживаемой платформы.

! ! !

ПРИМЕЧАНИЕ. Все файлы должны размещаться на дисках, находящихся под прямым управлением главной машины сервера Firebird.

. ! .

Изменение базы данных

Оператор ALTER DATABASE используется для добавления одного или более вторичных файлов к существующей базе данных. Он требует исключительного доступа к базе данных — см. разд. «Исключительный доступ»главы 39.

База данных может изменяться ее создателем (владельцем), пользователем SYSDBA или — для Linux/UNIX — любым пользователем с привилегиями операционной системы root.

Синтаксис

Синтаксис ALTER DATABASE:

ALTER {DATABASE | SCHEMA}

ADD <предложение-добавления>;

<предложение-добавления> = FILE ‘спецификация-файла’

<информация-о-файле> [<предложение-добавления>]

<информация-о-файле> = {LENGTH [=] целое [PAGE[S]] |

STARTING [AT [PAGE]] целое }

[<информация-о-файле>]

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

ALTER DATABASE

ADD FILE ‘mydatabase.fd2’ STARTING AT PAGE 10001

ADD FILE ‘mydatabase.fd3’ STARTING AT PAGE 20001 ;

Первичный и первый вторичный файл будет расти до 10 000 страниц. Если этого оказывается недостаточно для удовлетворения запросов к новым страницам, Firebird начнет сохранять новые страницы во втором вторичном файле.

Следующий пример задает длину вторичного файла, а не начальный номер страницы:

ALTER DATABASE

ADD FILE ‘mydatabase.fd2’ LENGTH 10000

ADD FILE ‘mydatabase.fd3’ ;

Результат несколько отличается от первого примера. В этом случае Firebird начнет использовать вторичный файл, когда первичный файл достигнет лимита файловой системы.

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

Кэш базы данных

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

* для версии 1.5 и выше это параметр DefauitDbCachePages в файле firebird.config для всех платформ;

* для версии 1.0.x это параметр database_cache_pages в файле isc_config (POSIX) или в ibconfig (Win32).

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

Вновь создаваемая база данных имеет размер кэша на уровне базы данных 0 страниц. Если установка кэша остается нулевой, то соединение с этой базой данных будет использовать установку на уровне сервера. Следовательно, база данных с большим размером страницы будет использовать больший объем памяти кэша, чем база данных с меньшим размером страницы.

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

Количество требуемых буферов кэша является приблизительным. Оно должно быть достаточно большим, чтобы удовлетворить требованиям баз данных к страницам, но не столь большим, чтобы занять память, необходимую другим операциям. До этого момента, чем больше работы может быть выполнено в кэше, тем лучше общая производительность. Аксиома «серверы баз данных любят RAM» истинна и для Firebird. Однако Firebird использует RAM для других видов деятельности, которые являются, по меньшей мере, столь же важными, что и кэширование. Транзакции и индексы поддерживаются в RAM, а, начиная с версии 1.5, сортировка и слияние данных также выполняются в памяти, если она доступна.

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

Ограничения и значения по умолчанию

Минимальный размер кэша- 50 страниц. Максимума не существует, пока выделяемый объем памяти не превышает доступный объем RAM.

Величиной выделяемого кэша по умолчанию является:

* Суперсервер. Для каждой выполняющейся базы данных 2048 страниц. Все пользователи совместно используют этот пул кэша.

Для оценки используемых ресурсов: одна выполняющаяся база данных с установками по умолчанию для PAGE_SIZE (4 Кбайт) и DefauitDbcachePages (2 Кбайт) требует 8 Мбайт памяти. Две базы данных, выполняющиеся с теми же установками, требуют 16 Мбайт и т.д. Используемый объем кэша по умолчанию вычисляется следующим образом:

PAGE_SIZE * DefaultDbCachePages * количество баз данных

* Классический сервер. Для каждого клиентского соединения 75 страниц кэша. Каждое соединение выделяет свой собственный кэш. Объем требуемой памяти является суммой требований к кэшу всех клиентских соединений со всеми базами данных. Используемый объем кэша вычисляется следующим образом:

PAGE_SIZE * DefaultDbCachePages * количество соединений

Вычисление размера кэша

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

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

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

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

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

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

Оценка требований к размеру

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

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

Коэффициент уменьшения r должен иметь значение между 0 и 1.

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

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

* для многофайловой базы данных возьмите значение STARTING AT первого вторичного файла и прибавьте значения LENGTH всех вторичных файлов.

Пусть DbCachePage равен количеству страниц кэша, требуемых для этой базы данных.

Для каждой базы данных вычислите:

DbCachePages = r * размер

Вычислите и запишите это число для каждой базы данных.

! ! !

СОВЕТ. Храните эти записи в другой документации по базе данных для использования, при необходимости, в настройке кэша индивидуальной базы данных.

. ! .

Вычисление потребностей в RAM

Для вычисления требуемого объема RAM для кэша базы данных на вашем сервере возьмите значение PAGE SIZE для каждой базы данных и умножьте на значение DefaultDbCachePages. Просуммированные результаты для всех баз данных дадут приблизительные требования к минимальному объему RAM для кэширования баз данных.

Установка размера кэша на уровне базы данных

Существует несколько способов конфигурирования размера кэша для конкретной базы данных. Изменения не действуют до тех пор, пока не будет установлено новое соединение с Суперсервером Firebird или не будет соединен новый клиент с Классическим сервером.

Использование gfix

Рекомендуемый способ установки значения на уровне базы данных для перекрытия значения DefaultDbCachePages — использование утилиты командной строки gfix со следующими переключателями:

gfix -buffers n имя-базы-данных

где n- требуемое количество страниц базы данных. Этот способ позволяет точно задать размер кэша базы данных, уменьшая риск «недоиспользования» памяти или работы со слишком малым размером кэша, когда на сервере используются несколько баз данных с разными требованиями к размеру кэша. Установленный таким способом размер кэша будет использован до тех пор, пока не будет задано новое значение.

! ! !

ПРИМЕЧАНИЕ. Для запуска gfix вы должны быть пользователем SYSDBA или владельцем базы данных. Более подробную информацию об использовании gfix см. в главе 39.

. ! .

Использование инструмента запросов командной строки isql

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

Первый вариант- включить количество страниц (n) как переключатель при запуске isql:

isql -с n имя-базы-данных

где n- количество используемых в сессии страниц кэша, которое временно перекрывает любое значение, установленное В DefaultDbCachePages (database_cache_pages) или в gfix. Должно быть больше 9.

В качестве альтернативы вы можете включить CACHE n В качестве аргумента оператора CONNECT при выполняющейся isql:

isql > connect имя-базы-данных CACHE n

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

Использование буфера параметров базы данных

В приложении размер кэша может быть установлен в буфере параметров базы данных (Database Parameter Buffer, DPB) с использованием параметра isc_dpb_num_buffers или isc_dpb_set_page_buf fers в соответствии с требованиями вашего сервера.

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

* isc_dpb_set_page_buffers — используется как в Классическом сервере, так и в Суперсервере. Этот параметр имеет тот же эффект, что и использование gfix для постоянного перекрытия DefaultDbCachePages.

! ! !

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

. ! .

Изменение значений по умолчанию для сервера

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

Для изменения установок откройте файл конфигурации в текстовом редакторе и найдите нужный параметр:

* для версии 1.5 уберите комментарий у DefaultDbCachePages и измените число;

* для версии 1.0.x в файле конфигурации это defauit_cache_pages. Если необходимо, уберите комментарий В строке и создайте запись default_cache_pages=nnnn, где nnnn — новый размер кэша.

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

Прагматичный подход

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

Хороший совет: не бросайтесь оптимизировать размер кэша для Firebird по принципу «обязан сделать». В процессе разработки используйте установки по умолчанию, а при установке системы просто проверьте, подходит ли объем доступной памяти RAM значениям по умолчанию.

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

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

После этого снова запустите мониторинг. Если описанная процедура не привела к улучшению дел, повторите упражнение.

Проверка размера кэша

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

ISQL> CONNECT имя-базы-данных;

ISQL> SET STATS ON;

ISQL> COMMIT;

Current memory = 415768

Delta memory = 2048

Max memory = 419840

Elapsed time = 0.03 sec

Buffers = 2048

Reads = 0

Writes 2

Fetches = 2

ISQL> QUIT;

После SET STATS ON пустая команда COMMIT указывает утилите isql на необходимость отображения информации об использовании памяти и буфера. Прочтите значение Buffers для определения текущего размера кэша в страницах.

Базы данных только для чтения

Базы данных по умолчанию создаются в режиме чтения/записи. Базы данных для чтения/записи не могут находиться на файловых системах только для чтения, даже если они используют только операторы SELECT, потому что Firebird записывает информацию о состоянии транзакций в структуру данных в файл базы данных. —

База данных Firebird может поставляться как файл только для чтения, при размещении каталогов, файлов и других, не относящихся к базе данных объектов, на ком- пакт-диски или другие файловые системы только для чтения. Конечно, к базам данных только для чтения могут также обращаться системы чтения/записи.

! ! !

ПРИМЕЧАНИЕ. База данных только для чтения — это не то же самое, что файл базы данных, у которого установлен атрибут только для чтения. Копирование файла базы данных для чтения/записи на компакт-диск не сделают ее базой данных только для чтения.

. ! .

Может потребоваться разработка приложения, которое не использует запросы, включающие запись в базу данных, или приложения, вызывающего исключение при попытках записи в базу данных. Следующие действия вызовут ошибку «Attempt to write to a read-only database» (Попытка записи в базу данных только для чтения):

* операции UPDATE, INSERT или DELETE;

* изменения метаданных;

* операции, которые пытаются увеличить генераторы.

Внешние файлы

Любые файлы, связанные с базой данных путем объявления

CREATE TABLE имя-таблицы EXTERNAL FILE ‘имя-файла’

будут так же открываться, как файлы только для чтения, даже если для файла не установлен атрибут только для чтения.

Преобразование базы данных в режим только для чтения

Требуется исключительный доступ для переключения базы данных между режимами чтения/записи и только для чтения- см. разд. «Исключительный доступ» главы 39. Переключение режима может быть выполнено владельцем базы данных или пользователем SYSDBA.

Могут быть использованы утилиты gfix или gbak^[37]:

* Используя gbak, выполните резервное копирование базы данных и восстановите ее в режиме только для чтения посредством опции -c[reate], например:

gbak -create -mode read_only dbl.fbk dbl.fdb

* Используя gflx, выдайте команду-m[ode] read-only, например: gfix -mode read_only dbl. fdb

! ! !

СОВЕТ. Восстанавливайте базы данных только для чтения с полностраничным заполнением — используйте переключатель -use для указания «использовать полное пространство». В базе данных для чтения/записи страницы по умолчанию заполняются примерно на 80 процентов, поскольку это может помочь в оптимизации повторного использования страниц. Резервирование пространства не имеет смысла для базы данных только для чтения, а полностью заполненные страницы являются более компактными и более быстрыми.

. ! .

! ! !

СОВЕТ. Хотя сервер Firebird может управлять напрямую базами данных InterBase 5.x, эти базы данных не могут быть переведены в режим только для чтения. Вы можете обновить базу данных InterBase 5 до базы данных только для чтения Firebird, сделав транспортабельную резервную копию в gbak InterBase 5 и восстановив с использованием gbak Firebird, с переключателями -c[reate] и -mode read_only.

. ! .

Теневые копии базы данных

Firebird имеет возможность немедленно восстанавливать базу данных в случае сбоя диска, сбоя сети, случайного удаления базы данных файловой системой^[38]. Теневое копирование (shadowing, аналог зеркалирования) является внутренним процессом, который поддерживает физическую копию базы данных в реальном времени. Всякий раз, когда изменения записываются в базу данных, теневая копия одновременно получает те же самые изменения.

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

Преимущества и ограничения теневого копирования

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

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

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

Теневое копирование является методом восстановления «все или ничего». Оно не обеспечивает восстановления отдельных фрагментов или возврата к конкретной временной точке. Оно может существовать только в той же файловой системе, что и сервер; теневая копия должна находиться на фиксированных дисках, расположенных на сервере. Она не может записываться на совместно используемые, не относящиеся к локальной файловой системе или удаленные устройства.

! ! !

ПРИМЕЧАНИЕ. На системах, поддерживающих NFS (Networking File System), возможна поддержка теневых копий на файловой системе NFS. Причем это не рекомендуется, поскольку теневая копия станет изолированной — а следовательно, бесполезной — при потере соединения.

. ! .

Важные предостережения

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

* Файл теневой копии не менее уязвим от «бросков и стрел жестокой фортуны», чем любые другие файлы вашей файловой системы.

* Одна потеря или повреждение файла теневой копии делает все теневое копирование бесполезным.

* Смерть диска или ненадежный модуль памяти способны принести огромный вред до того, как они полностью разрушат вашу базу данных. Каждый ошибочный фрагмент будет точно записан в теневую копию.

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

! ! !

СОВЕТ. Не будет серьезных проблем, если теневая копия случайно повреждена или удалена. Пока вы знаете, что случайности могут произойти, теневая копия для здоровья базы данных может быть восстановлена в любое время просто удалением копии и новым ее созданием.

. ! .

Реализация теневого копирования

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

Теневая копия, которая является одним дисковым файлом, называется файлом теневой копии. Теневая копия, состоящая из нескольких файлов, — которые могут располагаться более чем на одном диске, — называется набором теневых копий. Наборы теневых копий группируются в множество наборов теневых копий^[39].

Размещение и распределение файлов теневой копии

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

Дисковое устройство должно быть физически подключено к машине, на которой выполняется сервер Firebird. Файлы в наборе теневых копий могут находиться на разных дисках для улучшения ввода/вывода и выделения дискового пространства. Как и спецификации файлов базы данных, спецификации для теневых копий являются зависимыми от платформы.

Варианты теневой копии

Режим (AUTO или MANUAL)

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

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

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

* Если ставшая недоступной теневая копия была создана с атрибутом CONDITIONAL, Firebird автоматически создает новую теневую копию, если это возможно.

* Если теневое копирование не является условным, то понадобится заново создать теневую копию вручную.

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

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

Условное теневое копирование

Одной из причин, по которой теневая копия становится недоступной, является ситуация, когда она принимает на себя функции главной базы данных в случае «гибели» аппаратуры существующей базы данных — как-никак это основная идея теневого копирования^[40]!

! ! !

ВНИМАНИЕ! Атрибут CONDITIONAL должен также приводить к автоматическому созданию новой теневой копии, если существующая теневая копия становится операционной базой данных. Тем не менее практика показывает, что это происходит не всегда. Проверьте, работает ли это, как ожидалось, и будьте готовы использовать запасной вариант.

. ! .

Однофайловые теневые копии в сравнении с многофайловыми

По умолчанию теневая копия создается как «набор», содержащий один файл. Тем не менее набор теневой копии может включать в себя несколько файлов. Когда база данных- а следовательно, и ее теневая копия — увеличивается в размерах, теневая копия может быть переопределена и перегенерирована с большим количеством файлов, чтобы соответствовать требованиям увеличения пространства.

Создание теневой копии

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

Синтаксис:

CREATE SHADOW номер-набора [AUTO | MANUAL] [CONDITIONAL]

‘спецификация-файла’

[LENGTH [=] целое [PAGE[S]]] [<вторичный-файл>];

<вторичный-файл> = FILE ‘спецификация-файла’

[<информация-о-файле>] [<вторичный-файл>]

<информация-о-файле> =

{LENGTH [=] целое[PAGE[S]] | STARTING [AT [PAGE]]

целое} [<информация-о-файле>]

! ! !

СОВЕТ. Как и в операторе CREATE DATABASE, спецификация файлов для теневой копии всегда является зависимой от платформы.

. ! .

Однофайловая теневая копия

Предположим, у нас имеется сервер на Linux, соединенный с базой данных employee.gdb, которая размещена в каталоге примеров в корневом каталоге Firebird. Мы решили выполнять теневое копирование базы данных в разделе с именем /shadows. Для создания однофайловой теневой копии мы используем оператор

CREATE SHADOW 1 ‘/shadows/employee.shd’;

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

Используем команду isql SHOW DATABASE, чтобы убедиться, что теневая копия сейчас существует:

SQL> SHOW DATABASE;

Database: /usr/local/firebird/examples/employee.gdb

Shadow 1: ‘/shadows/employee.shd’ auto

PAGE_SIZE 4096

Number of DB pages allocated = 392

Sweep interval = 20000

. . .

Многофайловая теневая копия

Синтаксис создания многофайловой теневой копии похож на синтаксис создания многофайловой базы данных: спецификация вторичного файла теневой копии «сцепляется» со спецификацией первичного файла с указанием спецификаций и ограничений размеров каждого файла.

В следующем примере предположим, что мы соединены с базой данных employee.gdb, расположенной в каталоге по умолчанию Win32. Мы собираемся создавать теневую копию из трех файлов на дисках F, H и J, которые являются разделами жесткого диска файловой системы сервера.

! ! !

СОВЕТ. Размеры вторичных файлов теневой копии не обязательно должны соответствовать размерам вторичных файлов базы данных.

. ! .

Первичный файл (employee1.shd) имеет длину 10 000 страниц базы данных, а первый вторичный файл (employee2.shd) 20 000 страниц базы данных. Как и в случае с базой данных, последний вторичный файл теневой копии при необходимости будет увеличиваться, пока не будет исчерпано дисковое пространство раздела или пока не будет достигнут предел размера для файловой системы.

CREATE SHADOW 25 ‘F:shadowsemployeel.shd’ LENGTH 10000

FILE ‘H:shadowsemployee2.shd’ LENGTH 20000

FILE ‘J:shadowsemployee3.shd’ ;

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

CREATE SHADOW 25 ‘F:shadowsemployeel.shd’

FILE ‘H:shadowsemployee2.shd’ STARTING AT 10001

FILE ‘J:shadowseraployee3.shd’ STARTING AT 30001;

Вы можете проверить в isql:

SQL> SHOW DATABASE;

Database: C:Programfirebirdexamplesemployee.gdb

Owner: SYSDBA

Shadow 25: ‘F:SHADOWSEMPLOYEEl.SHD’ auto length 10000

file H:SHADOWSEMPLOYEE2.SHD starting 10001

file J:SHADOWSEMPLOYEE3.SHD starting 30001

PAGE_SIZE 1024

Number of DB pages allocated =462

Sweep interval = 20000

Ручной режим

В предыдущих примерах создавались теневые копии в режиме по умолчанию AUTO. Предположим, что теперь нам нужно, чтобы работа базы данных была остановлена каждый раз, когда работа с базой данных или ее теневой копией становится невозможной по различным причинам. В этом случае нам нужно создавать теневую копию в режиме MANUAL (см. предыдущие примечания в этом разделе). Для сообщения серверу Firebird, что мы хотим установить это правило, мы создаем теневую копию с использованием ключевого слова MANUAL в операторе CREATE SHADOW:

CREATE SHADOW 9 MANUAL ‘/shadows/employee.shd’;

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

Условная теневая копия

Во всех предыдущих примерах спецификация CREATE SHADOW оставляла базы данных без теневого копирования после того, как теневая копия становилась недоступной по причине отключения от базы данных или когда она «занимала место» активной базы данных при физической смерти оригинальной базы данных.

В случае теневой копии режима MANUAL это то, что нам нужно.

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

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

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

CREATE SHADOW 33 CONDITIONAL ‘/shadows/employee.shd’;

Увеличение размера теневой копии

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

Удаление теневой копии

Теневую копию нужно удалять в следующих ситуациях:

* это «ручная» теневая копия, которая по разным причинам была отключена от системы. Удаление ненужной теневой копии является необходимым для создания новой теневой копии и возобновления обслуживания базы данных;

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

* вам нужно изменить размеры файлов теневой копии, добавить больше файлов или установить новую теневую копию с другими атрибутами;

* теневое копирование больше не требуется. Удаление теневой копии означает отключение теневого копирования.

Удаление теневой копии удаляет не только физические файлы, но также и ссылки на нее из метаданных базы данных. Чтобы иметь право на выполнение этой команды, вы должны быть соединены с базой данных как пользователь, который создал теневую копию, пользователь SYSDBA или (в POSIX) пользователь с привилегиями операционной системы root.

Синтаксис

Используйте следующий синтаксис DROP SHADOW:

DROP SHADOW номер-набора-теневой-копии;

Номер набора теневой копии является обязательным аргументом команды DROP SHADOW. Для отыскания этого номера используйте в isql команду SHOW DATABASE, будучи подключенным к этой базе данных.

В следующем примере удаляются все файлы, связанные с набором оперативной копии за номером 25:

DROP SHADOW 25;

Использование gfix-переключателя -kill

Служебная утилита командной строки gfix (см. главу 39) имеет переключатель -kill, который внутренне вызывает команду DROP SHADOW, чтобы удалить теневую копию и сделать ее недоступной. После выполнения этой команды можно будет продолжить создание новых теневых копий.

Например, для удаления недоступной теневой копии нашей базы данных employee в POSIX наберите:

[root@coolduck bin]# ./gfix -kill ../examples/employee.gdb -user SYSDBA

-password masterkey

В Win32 наберите:

C:Program FilesFirebirdbin> gfix -kill ..examplesemployee.gdb

-user SYSDBA -password masterkey

«Гигиена» базы данных

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

Фоновая сборка мусора

Для ограничения такого разрастания Firebird постоянно выполняет сборку мусора (garbage collection) на фоне активности базы данных.

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

Чистка базы данных

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

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

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

Интервал очистки

Сервер Firebird поддерживает инвентаризацию транзакций. Самая старая из транзакций, которые помечены в инвентарном списке как завершенные по rollback, называется «старейшей заинтересованной» (Oldest Interesting Transaction, OIT, или Oldest transaction), и обозначает начальную точку для интервала очистки. Если интервал очистки больше нуля, Firebird запускает полную чистку базы данных, когда разница между OIT и транзакцией Oldest snaphsot превышает порог, установленный для интервала очистки.

Инструкции см. в главе 39.

Сборка мусора в процессе резервного копирования

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

! ! !

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

. ! .

Информацию о преимуществах резервного копирования и восстановления см. в главе 38.

Проверка и ремонт

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

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

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

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

Когда проверять достоверность и зачем

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

* ошибки «corrupt database» или «consistency check»;

* резервное копирование, которое закончилось ненормально;

* отказ или изменение напряжения электропитания при отсутствии источника бесперебойного питания (UPS) или при предположении об отказе UPS;

* предполагаемые или сообщенные системой ошибки жесткого диска, сети или памяти;

* теневая копия заменяет собой базу данных после разрушения диска;

* база данных была перенесена с другой платформы или системы хранения;

* ожидаемое несанкционированное обращение к сети или базе данных со стороны внешних атак.

Подробности использования gfix для выполнения проверки базы данных см. в главе 39.

Что делать с разрушенной базой данных

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

В приложении 4 содержится подробное описание процедур починки разрушенной базы данных.

Как разрушить базу данных Firebird

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

Модификация системных таблиц

Firebird хранит и ведет все свои метаданные и ваши определенные пользователем объекты в… базе данных Firebird! Более точно он хранит их в отношениях (таблицах) прямо в самой базе данных. Идентификаторы системных таблиц, их столбцов и некоторых других типов системных объектов начинаются с символов «RDB$».

Поскольку это обычные объекты базы данных, их можно запрашивать и манипулировать ими как определенными пользователем объектами. Однако то, что вы можете., не означает, что вы должны.

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

Отмена принудительной записи для Firebird 1.0.x в Windows

Firebird по умолчанию устанавливается с возможностью принудительной записи (forced writes, синхронной записью). Измененные и новые данные записываются на диск немедленно после завершения операции (post).

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

Сервер платформ Win32 не сохраняет на диск кэш сервера Firebird 1.0.x, пока не будет закрыт сервис Firebird. Не говоря уже о сбое в питании, может много чего плохо- го произойти с сервером Windows. Если он зависнет, система ввода/вывода прекратит работу, и работа вашего пользователя будет потеряна в процессе перезагрузки.

Серьезное предупреждение: не отключайте принудительную запись на сервере Windows, если вы не используете Firebird 1.5 и выше.

Firebird 1.5 по умолчанию сбрасывает кэш на диск каждые 5 секунд или каждые 100 операций записи- что произойдет быстрее. Эта частота может быть изменена В firebird.conf корректировкой одного или двух параметров MaxUnflushedWrites и MaxUnflushedWriteTime.

Windows 95 не поддерживает асинхронную запись на диск.

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

Восстановление резервной копии в работающую базу данных

Один из режимов восстановления в утилите gbak (gbak -r[estore]) позволяет восстанавливать файл резервной копии поверх существующей базы данных — база данных перезаписывается. В этом режиме возможно восстановление без предупреждения о том, что пользователи соединены с базой данных. Разрушение базы данных является практически гарантированным результатом.

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

Чтобы сделать это практически, рекомендуется восстанавливать базу на резервное дисковое пространство, используя gbak -с[reate]. Прежде чем сделать восстановленную базу данных активной, проверьте ее в резервной области, используя isql или ваш предпочитаемый инструмент администратора.

Разрешение пользователям соединяться с базой данных в процессе ее восстановления

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

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

Используйте любую утилиту копирования или архивирования файловой системы (DOS copy, xcopy, tar, gzip, WinZip, WinRAR и т.д.) для копирования файлов базы данных, в то время как с ней соединены любые пользователи (включая SYSDBA). Копия будет поврежденной, но еще хуже, система блокировки и/или кэширования этих программ может привести к потере данных и, возможно, к разрушению исходного файла.

Удаление базы данных

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

Командой удаления базы данных является DROP DATABASE; она не имеет параметров. При выполнении команды вы должны быть соединены с базой данных как ее владелец, пользователь SYSDBA или (в Linux/UNIX) как пользователь с привилегиями операционной системы root.

Синтаксис

Если, будучи соединенным с базой данных, вы захотите ее удалить, используйте для этого оператор:

DROP DATABASE;

После удаления база данных не может быть восстановлена, следовательно:

* будьте уверены, что вы действительно хотите, чтобы она была потеряна навсегда;

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

Пора дальше

Создание базы данных инсталлирует инфраструктуру, необходимую для начала создания объектов. Первичным объектом для постоянного хранения данных в базе данных является таблица. В отличие от электронных таблиц, большинства настольных систем управления данными и даже одного или двух кандидатов на «профессиональную» реляционную СУБД Firebird не сохраняет данные в структурах, которые являются «табличными» в виде упорядоченных строк и столбцов, распознаваемых файловой системой. Firebird управляет собственным дисковым пространством и использует собственные правила для размещения и отображения постоянных данных. Он поддерживает множество способов выделения данных в подобные таблицам наборы. В следующей главе мы начнем с создания постоянного SQL-объекта TABLE.

ГЛАВА 16. Таблицы.

В терминологии SQL-89 и SQL-92 таблицы Firebird являются постоянными базовыми таблицами. Эти стандарты определяют некоторые другие типы, включая просматриваемые таблицы, которые Firebird реализует в виде просмотров (view, см. главу 24), и производные таблицы (derived tables), которые Firebird реализует в виде хранимых процедур выбора (см. главы 28 и 30).

О таблицах Firebird

В отличие от настольных баз данных, таких как Paradox и dBase, база данных Firebird не является серией «табличных файлов», физически организованных в виде строк и столбцов. Firebird хранит данные, независимо от их структуры в сжатом формате на страницах базы данных. Он может хранить одну или более записей — или, более правильно, строк- данных таблицы на одной странице. В случаях, когда данные одной строки слишком велики, чтобы разместиться на одной странице, строка может размещаться на нескольких страницах.

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

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

Метаданные- физические описания таблиц, их столбцов и атрибутов, так же как и описания всех других объектов — сами хранятся в обычных таблицах Firebird внутри базы данных. Сервер Firebird изменяет данные в этих таблицах, когда объекты базы данных создаются, изменяются или удаляются. Он постоянно к ним обращается при выполнении операций над строками. Такие таблицы называются системными таблицами. Более подробную информацию см. в разд. «Системные таблицы» в самом начале главы 14. Схемы системных таблиц см. в приложении 9.

Создание таблиц

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

* вы должны создать базу данных для их размещения — инструкции см. в главе 15;

* вы должны соединиться с базой данных;

* если вы планируете использовать домены для определения типов данных столбцов ваших таблиц, вы должны уже создать домены (см. главу 13).

Владение таблицами и привилегии

Когда создается таблица, Firebird автоматически применяет к ним безопасность схемы по умолчанию. Человеку, который создает таблицу (ее владелец), назначаются к ней все привилегии SQL, включая право передавать привилегии другим пользователям, триггерам и хранимым процедурам. Ни один другой пользователь, за исключением SYSDBA, не будет иметь никакого доступа к этой таблице, пока явно не получит привилегии.

! ! !

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

. ! .

Информацию о привилегиях SQL см. в главе 35.

Оператор CREATE TABLE

В DDL для создания таблиц используется оператор CREATE TABLE. Его синтаксис:

CREATE TABLE таблица

[EXTERNAL [FILE] ‘спецификация-файла’]

(<определение-столбца>

[, <определение столбца>

| <ограничение-таблицы> …]);

Самый первый основной аргумент в CREATE TABLE- идентификатор таблицы^[41]. Он является обязательным и должен быть уникальным среди всех имен таблиц, просмотров и процедур базы данных, иначе вы не сможете создать таблицу. Вы также должны предоставить определение, по крайней мере, одного столбца.

Определение столбцов

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

Синтаксис определения столбца:

<определение-столбца> = столбец

{тип-данных | COMPUTED [BY] (<выражение>) | домен}

[DEFAULT {литерал | NULL | USER} ]

[NOT NULL] [<ограничение-столбца>]

[COLLATE порядок-сортировки]

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

Требуемые атрибуты

Приведем требуемые атрибуты.

* Идентификатор столбца (имя), уникальный среди столбцов этой таблицы.

* Одно из следующих:

• тип данных SQL;

• выражение для вычисляемого столбца;

• имя домена для столбцов, основанных на доменах. Столбцы разделяются запятыми, например:

CREATE TABLE PERSON (

PERSON_ID BIGINT NOT NULL,

FIRST_NAME VARCHAR (35),

LAST_NAMES VARCHAR (80),

FULL_NAME COMPUTED BY FIRST_NAME ||’ ‘|| LAST_NAMES,

PHONE_NUMBER TEL_NUMBER) ;

Столбец FULL_NAME является вычисляемым столбцом, который вычисляется конкатенацией двух других описанных столбцов: FIRST_NAME и LAST_NAME. Мы вернемся к вычисляемым столбцам несколько позже. Ограничение NOT NULL применяется к PERSON ID, потому что мы хотим сделать его первичным ключом (детали рассмотрим позже).

Для столбца PHONE_NUMBER мы используем домен, который был определен в нашем примере в главе 13:

CREATE DOMAIN TEL_NUMBER

AS VARCHAR(18)

CHECK(VALUE LIKE ‘ (0%)%’);

Столбцы, основанные на доменах

Если определение столбца основано на домене, оно может включать новое значение по умолчанию, дополнительные ограничения CHECK, предложение COLLATE, которые перекрывают значения, уже определенные в определении домена. Оно также может включать дополнительные атрибуты или ограничения столбца. Например, вы можете добавить ограничение NOT NULL для столбца, если домен его еще не содержит.

! ! !

ВНИМАНИЕ! Домен, который был определен как NOT NULL, не может быть переопределен на уровне столбца, как допускающий пустое значение.

. ! .

Например, следующий оператор создает таблицу COUNTRY, ссылающуюся на домен с именем COUNTRYNAME, который не имеет ограничения NOT NULL:

CREATE TABLE COUNTRY (

COUNTRY COUNTRYNAME NOT NULL PRIMARY KEY,

CURRENCY VARCHAR(10) NOT NULL);

Мы добавили ограничение NOT NULL в определение столбца COUNTRYNAME, потому что он будет первичным ключом таблицы COUNTRY.

Необязательные атрибуты

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

Значение DEFAULT

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

Например, возможным значением по умолчанию для столбца TIMESTAMP может быть контекстная переменная CURRENT_TIMESTAMP (серверная дата и время). В символьном столбце логического стиля (True/False) значение по умолчанию может быть установлено в ‘ F’ , чтобы гарантировать, что допустимое, непустое значение будет записано в каждую новую строку.

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

* константой (например, строкой, числом или датой);

* контекстной переменной (например, CURRENT_TIMESTAMP, CURRENT_USER^[42], CURRENT_CONNECTION и т.д.);

* предварительно определенным литералом даты (таким как ‘NOW’, ‘TOMORROW’ и т.д.);

* NULL может быть установлен как значение по умолчанию только для столбцов, допускающих пустое значение^[43]. Столбец, допускающий пустое значение, получает значение по умолчанию NULL автоматически, однако вам может понадобиться перекрыть нежелательное значение по умолчанию на уровне домена. Не объявляйте это значение по умолчанию для столбцов, имеющих ограничение NOT NULL.

! ! !

ВНИМАНИЕ! Когда вы полагаетесь на значение по умолчанию, вы должны понимать, что значение по умолчанию будет применяться только к добавлению новой строки и только если оператор INSERT не включает этот столбец со значением по умолчанию в список столбцов. Если ваше приложение включает этот столбец в оператор INSERT и передает NULL в списке значений, то NULL и будет сохранен, независимо от любого определенного значения по умолчанию. Если столбец не допускает пустых значений, то передача значения NULL всегда вызовет исключение.

. ! .

Следующий пример определяет столбец CREATED_BY, который имеет в качестве значения по умолчанию контекстную переменную CURRENT_USER:

CREATE TABLE ORDER (

ORDER_DATE DATE,

CREATED_BY VARCHAR (31) DEFAULT CUREENT_USER,

ORDER_AMOUNT DECIMAL(15,2));

Новая строка добавляется пользователем JILLIBEE; столбец CREATED_BY не указан в списке столбцов:

INSERT INTO ORDER (ORDER_DATE, ORDER_AMT)

VALUES (’15-SEP-2004′, 1004.42);

Запрос к этой таблице:

SELECT * FROM ORDER;

. . .

ORDER_DATE CREATED_BY ORDER_AMOUNT

. . .

15-SEP-2004 JILLIBEE 1004.42

. . .

Предложение CHARACTER SET

Набор символов (CHARACTER SET) используется для индивидуального символьного столбца или текстового столбца BLOB, когда вы определяете столбец. Если вы не задаете набор символов, то столбец принимает набор символов домена, если определен, иначе он принимает набор символов по умолчанию для базы данных. Пример:

CREATE TABLE TITLES_RUSSIAN (

TITLE_ID BIGINT NOT NULL,

TITLE_EN VARCHAR(100),

TITLE VARCHAR(100) CHARACTER SET WIN1251);

Подробнее о наборах символов см. главу 11. Список доступных наборов символов представлен в приложении 8.

Предложение COLLATE

Предложение COLLATE может быть добавлено к столбцам CHAR и VARCHAR для перекрытия последовательности сортировки, определенной для набора символов столбца в домене, на котором основывается столбец. Последовательность сортировки не применима для типов BLOB.

Следующее расширение предыдущего примера включает предложение COLLATE:

CREATE TABLE TITLES_RUSSIAN (

TITLE_ID BIGINT NOT NULL,

TITLE_EN VARCHAR(100),

TITLE VARCHAR(100) CHARACTER SET WIN1251 COLLATE PXW_CYRL);

! ! !

ВНИМАНИЕ! Будьте осторожны при применении предложения COLLATE К столбцам, которые должны быть индексированы. Максимальный размер индекса 252 байта может быть радикально уменьшен при некоторых последовательностях сортировки. Сначала проверьте! (Для COLLATE PXW_CYRL он уменьшается до 84 символов.)

. ! .

Подробности о последовательностях сортировки, доступных для каждого набора символов, см. в главе 11. Список доступных наборов символов и порядков сортировки см. в приложении 8.

! ! !

СОВЕТ. Вы можете получить собственный список, который может включать и более поздние последовательности сортировки, создав новую базу и выполнив запрос из разд. «Отображение доступных последовательностей сортировки» главы 11.

. ! .

Вычисляемые столбцы

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

Синтаксис:

<имя-столбца> COMPUTED [BY] (<выражение>);

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

Приведем другие существующие ограничения для вычисляемых столбцов.

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

* Вычисляемый столбец не может быть определен как массив или возвращать массив.

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

* Вычисляемые столбцы не могут быть индексированы.

* Ограничения, помещенные для вычисляемого столбца, будут проигнорированы.

* Вычисляемые столбцы используются только для вывода и только для чтения. Включение их в операторы INSERT или UPDATE вызовет исключение.

! ! !

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

. ! .

Примеры вычисляемых столбцов

Следующий оператор создает вычисляемый столбец FULL NAME путем конкатенации столбцов LAST_NAMES и FIRST_NAME.

CREATE TABLE PERSON (

PERSON_ID BIGINT NOT NULL,

FIRST_NAME VARCHAR(35) NOT NULL,

LAST_NAMES VARCHAR (80) NOT NULL,

FULL_NAME COMPUTED BY FIRST_NAME ||’ ‘ || LAST_NAMES) ;

/**/

SELECT FULL_NAME FROM PERSON

WHERE LAST_NAMES STARTING WITH ‘SMI’;

FULL NAME

=============

Arthur Smiley

John Smith

Mary Smits

! ! !

ПРИМЕЧАНИЕ. Обратите внимание на ограничения NOT NULL В двух именах, объединяемых для вычисляемого столбца. Важно обращать внимание на такие детали в случае вычисляемых столбцов, потому что NULL как элемент конкатенации всегда будет давать результат NULL.

. ! .

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

CREATE TABLE SNIFFIT

(SNIFFID INTEGER NOT NULL,

SNIFF COMPUTED BY (CURRENT_USER),

SNIFFDATE COMPUTED BY (CURRENT_TIMESTAMP));

/**/

SELECT FIRST 1 FROM SNIFFIT;

SNIFFID SNIFF SNIFFDATE

===== ===== =====

1 SYSDBA 2004-08-15 08:15:35.0000

Следующий пример создает таблицу с вычисляемым столбцом (NEW_PRICE), который использует ранее созданные определения для OLD_PRICE и PERCENT_CHANGE:

CREATE TABLE PRICE_HISTORY (

PRODUCT_ID D_IDENTITY NOT NULL, /* использует домен */

CHANGE_DATE DATE DEFAULT CURRENT_TIMESTAMP NOT NULL,

UPDATER_ID D_PERSON NOT NULL, /* использует домен */

OLD_PRICE DECIMAL(13,2) NOT NULL,

PERCENT_CHANGE DECIMAL (4, 2)

DEFAULT 0

NOT NULL

CHECK (PERCENT_CHANGE BETWEEN -50.00 AND 50.00);

NEW_PRICE COMPUTED BY

(OLD_PRICE + (OLD PRICE * PERCENT_CHANGE / 100)) );

Ограничения

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

Ограничения видны всем транзакциям, которые выполняют доступ к базе данных, и автоматически применяются на сервере. Они различаются их областью действия. Некоторые, такие как NOT NULL, напрямую применяются к одному столбцу (ограничения столбца), в то время как другие, такие как PRIMARY KEY и некоторые ограничения CHECK, имеют эффект на уровне таблицы (ограничения таблицы). Ограничение FOREIGN KEY имеет область действия таблица-таблица.

Ограничения существуют «в своих собственных правах» как объекты в базе данных Firebird. Каждое ограничение уникально представлено в метаданных с правилами и зависимостями, которые представлены обычными отношениями между системными таблицами.

Ограничения целостности

Ограничения целостности устанавливают правила, которые управляют состоянием доступных элементов данных или отношением между столбцом и таблицей, как целое — часто и тем, и другим. Примерами являются NOT NULL (не допускает ввод, содержащий неопределенное значение), UNIQUE (требует, чтобы вводимый элемент не имел соответствующего значения этого столбца в таблице) и PRIMARY KEY (объединяет два других ограничения, а также «представляет» таблицу для ссылочного отношения с другими таблицами).

Каждое из ограничений целостности подробно обсуждается позже в этой главе.

Ссылочное ограничение

Ссылочное ограничение реализовано как FOREIGN KEY. Ограничение внешнего ключа существует только в контексте другой таблицы и уникального ключа этой таблицы, заданного явно или неявно в предложении REFERENCES при объявлении ограничения.

Таблицы, связанные в отношении внешнего ключа, называются связанными ограничением ссылочной целостности. Следовательно, любой столбец или группа столбцов, ограниченная в ограничениях PRIMARY KEY или UNIQUE, также потенциально являются субъектами ссылочных ограничений.

Ссылочная целостность подробно обсуждается в главе 17.

Именованные ограничения

При объявлении ограничения на уровне таблицы или на уровне столбца вы можете именовать ограничение, используя предложение CONSTRAINT. Если вы опустите предложение CONSTRAINT, Firebird сгенерирует уникальное системное имя ограничения. Ограничения хранятся в системной таблице RDB$RELATION_CONSTRAINTS.

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

Имена для PRIMARY KEY и FOREIGN KEY

Именование ограничения имеет особый смысл для ограничений PRIMARY KEY и FOREIGN KEY, особенно в Firebird 1.5 и выше. Существует возможность перекрыть «родные» для Firebird ограничения по именованию ключей.

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

* в версии 1.5 и более поздних поддерживающий ограничение индекс будет иметь то же самое имя, что и ограничение;

* в версии 1.0.x будет использовано имя индекса по умолчанию (RDB$PRIMARYnn или RDB$FOREIGNnn).

! ! !

ПРИМЕЧАНИЕ. Существующие имена ограничений останутся без изменений при переводе базы данных с сервера версии 1.0.x на сервер версии 1.5.

. ! .

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

Ограничения целостности

Ограничение NOT NULL

Firebird не поддерживает атрибут указания допустимости пустого значения, как это делают некоторые нестандартные СУБД. В соответствии со стандартами все столбцы в Firebird могут содержать пустое значение, если не будет явно указано ограничение NOT NULL. Необязательное ограничение NOT NULL является ограничением на уровне столбца, которое может быть применено, чтобы заставить пользователя вводить значение. NULL не является значением, так что любая попытка ввести NULL В столбец или установить его в значение NULL приведет к исключению.

Поскольку роль ограничения NOT NULL заключается в формировании ключей, вы должны знать относительно него некоторые ограничения.

* Оно должно применяться к определению любого столбца, который будет включен в ограничение PRIMARY KEY или UNIQUE.

* В Firebird 1,0.x оно должно применяться к определению любого столбца, который будет включен в ограничение UNIQUE или в уникальный индекс.

* Оно не может быть удалено из домена или столбца операторами ALTER DOMAIN или ALTER TABLE, ALTER COLUMN или перекрыто на уровне столбца. Не используйте домен NOT NULL для определения столбца, который может иметь значение NULL.

Для большего понимания NULL см. разд. «Обсуждение NULL» главы 21.

Ограничение PRIMARY KEY

PRIMARY KEY является ограничением целостности на уровне столбца — набор поддерживаемых правил, — которое формально отмечает столбец или группу столбцов как уникальный идентификатор для каждой строки в таблице.

Если вы пришли в Firebird из СУБД, которые поддерживают концепцию «первичного индекса» для определения ключа (обычно основанные на файлах системы, такие как Paradox, Access и MySQL), то Firebird и мир стандартов SQL вам понятны. Первичный ключ является не индексом, а ограничением. Одним из правил для такого ограничения является то, что ограничение должно иметь определенный уникальный индекс из одного или более связанных с ним непустых элементов.

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

! ! !

ВНИМАНИЕ! Не надо импортировать существующий «первичный индекс» из наследуемой системы, основанной на файлах, или создавать такой индекс в ожидании объявления ограничения первичного ключа. Firebird не может накладывать ограничение первичного ключа поверх существующего индекса — по крайней мере в существующих версиях, включая 1.5, — а оптимизатор запросов не будет правильно работать при дублировании индексов.

. ! .

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

! ! !

ВНИМАНИЕ! Если вы конвертируете базу данных в Firebird из любого другого источника за исключением InterBase или Oracle, то вы должны обратить особое внимание на схему в отношении имен и ограничений первичного ключа.

. ! .

Хотя само ограничение PRIMARY KEY не является ссылочным ограничением, оно обычно является обязательной частью любого ссылочного ограничения, будучи потенциальным объектом предложения REFERENCES ограничения FOREIGN KEY. Подробности см. в главе 17.

Выбор первичного ключа

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

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

* Атрибут NOT NULL должен быть объявлен для всех столбцов в группе из одного или более столбцов. Целостность ключа может быть осуществлена только сравнением значений, a NULL не является значением.

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

К этим теоретическим «установкам» должна быть добавлена третья.

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

Как реальные данные могут привести вас к неудаче

Используя таблицу EMPLOYEE базы данных employee.fdb из каталога /examples корневого каталога Firebird (employee.gdb в версии 1,0.x), давайте посмотрим, как реальные данные могут привести к ошибочности ваших теоретических предположений об уникальности. Вот объявление, которое показывает имеющие смысл данные, хранимые в этой таблице:

CREATE TABLE EMPLOYEE (

FIRST_NAME VARCHAR(15) NOT NULL,

/* предположение: служащий должен иметь имя */

LAST_NAME VARCHAR(20) NOT NULL,

/* предположение: служащий должен иметь фамилию */

PHONE_EXT VARCHAR(4),

HIRE_DATE DATE DEFAULT CURRENT_DATE NOT NULL,

DEPT_NO CHAR(3) NOT NULL,

JOB_CODE VARCHAR (5) NOT NULL,

JOB_GRADE SMALLINT NOT NULL,

JOB_COUNTRY VARCHAR(15) NOT NULL,

SALARY NUMERIC (15, 2) DEFAULT 0 NOT NULL,

FULL_NAME COMPUTED BY FIRST_NAME || ‘ ‘ || LAST_NAME ) ;

Фактически эта структура не имеет кандидата в ключи. Невозможно идентифицировать одну строку служащего, используя (FIRST_NAME, LAST_NAME) в качестве ключа, поскольку комбинация двух элементов с вероятностью от средней до высокой может дублироваться в организации. Мы не сможем сохранить записи двух служащих с именем John Smith.

Для получения ключей необходимо что-то изобрести. Это «что-то» — механизм, известный как суррогатный ключ.

Суррогатные ключи

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

CREATE DOMAIN EMPNO SMALLINT ;

COMMIT;

ALTER TABLE EMPLOYEE

ADD EMP_NO EMPNO NOT NULL,

ADD CONSTRAINT PK_EMPLOYEE

PRIMARY KEY(EMP_NO) ;

Эта база данных также содержит генератор с именем EMP_NO_GEN и триггер Before insert (перед добавлением) с именем SET_EMP_NO для таблицы EMPLOYEE для получения значения данного ключа в момент добавления новой строки. В разд. «Реализация автоинкрементных ключей» главы 31 эта техника описывается в деталях. Это рекомендованный способ реализации суррогатных ключей в Firebird.

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

Составные первичные ключи

В процессе анализа данных иногда в структуре данных можно отыскать единственный уникальный столбец. Теория советует найти два или более столбцов, сгруппированных вместе в качестве ключа, которые будут гарантировать уникальность строки. Когда множество столбцов объединяются для формирования ключа, такой ключ называется составным ключом (composite key) или иногда сложным ключом.

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

В Firebird нет необходимости в составных индексах и, более того, составные индексы создают некоторые проблемы как

для разработки, так и для производительности в случае больших таблиц.

* Составные ключи обычно являются составленными из неатомарных элементов ключа- т.е. выбранные столбцы имеют смысловое значение (они являются «значимыми данными») и, несомненно, уязвимы для внешних изменений и ошибок ручного ввода.

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

* Ключи — внешние, так же как и первичные — имеют постоянные индексы. Составные индексы имеют более строгие ограничения по размеру, чем индексы из одного столбца.

* Составные индексы имеют тенденцию к большим размерам. Большие индексы используют больше страниц базы данных, что приводит к тому, что индексные операции (сортировка, соединение и сравнение) выполняются медленнее, чем необходимо.

Атомарность столбцов первичного ключа

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

Чтобы первичный ключ был атомарным, нужно быть вне человеческих решений. Если люди составляют его или классифицируют его, он не является атомарным. Если он является субъектом любого правила за исключением требований NOT NULL и уникальности, он не является атомарным. В приведенном ранее примере даже водительские права или номер социального обеспечения не соответствуют требованиям атомарности для первичного ключа, потому что они являются субъектами внешних систем.

Синтаксис объявления первичного ключа

Можно использовать несколько вариантов синтаксиса для назначения ограничения PRIMARY KEY столбцу или группе столбцов. Все столбцы, являющиеся элементами первичного ключа, должны быть предварительно определены с атрибутом NOT NULL. Так как нельзя добавить ограничение NOT NULL в столбец после его создания, необходимо позаботиться об этом ограничении до использования других ограничений.

Ограничение PRIMARY KEY может применяться в любой из следующих фаз создания метаданных:

* в определении столбца в операторах CREATE TABLE или ALTER TABLE как часть определения столбца;

* в определении таблицы в операторах CREATE TABLE или ALTER TABLE как отдельно определенное ограничение таблицы.

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

В следующей последовательности создается и подтверждается (commit) домен, не допускающий пустое значение, затем определяется столбец первичного ключа, основанный на этом домене, и одновременно применяется ограничение PRIMARY KEY к этому столбцу:

CREATE DOMAIN D_IDENTITY AS BIGINT NOT NULL;

COMMIT;

CREATE TABLE PERSON (

PERSON_ID D_IDENTITY PRIMARY KEY,

Firebird создает ограничение таблицы с именем INTEG_M и индекс с именем RDB$PRIMARYnn. (пл в каждом случае — число, полученное от генератора. Эти два числа не связаны друг с другом.) Вы не можете повлиять на то, какими будут эти имена, и не можете поменять их.

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

ALTER TABLE BOOK

ADD BOOK_ID D_IDENTITY PRIMARY KEY;

Определение первичного ключа как именованного ограничения

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

CREATE TABLE ATABLE (

ID BIGINT NOT NULL,

ANOTHER_COLUMN VARCHAR (20),

CONSTRAINT PK_ATABLE PRIMARY KEY(ID) );

Теперь вместо использования сгенерированного системой имени RDB$PRIMARYnnn Firebird использует PK_ATABLE В качестве имени этого ограничения. В Firebird 1.5 и выше он также применяет определенное пользователем имя ограничения для поддерживающего уникального индекса. В этом примере индекс получит имя PK_ATABLE, когда в других версиях его имя будет RDB$PRIMARYnnn.

Firebird 1.5 также позволяет использовать определенные пользователем имена для ограничения и поддерживающего его индекса.

Использование пользовательского индекса

До Firebird 1.5 не было возможности использовать убывающий индекс для поддержки первичного ключа. Начиная с версии 1.5, можно поддерживать первичный ключ убывающим индексом. Чтобы это сделать, в Firebird 1.5 добавляется расширение синтаксиса в форме предложения USING, позволяющего создавать индекс ASC[ENDING] (по возрастанию) или DESC [ENDING] (по убыванию) и присваивать ему имя, отличное от имени ограничения.

AS с и DESC определяют направление поиска. Подробнее эта концепция обсуждается в главе 18.

Следующий оператор создаст ограничение первичного ключа с именем PK ATEST и поддерживающий его убывающий индекс с именем IDX_PK_ATEST:

CREATE TABLE ATEST (

ID BIGINT NOT NULL,

DATA VARCHAR(10));

COMMIT;

ALTER TABLE ATEST

ADD CONSTRAINT PK_ATEST PRIMARY KEY(ID)

USING DESC INDEX IDX_PK_ATEST;

COMMIT;

Альтернативный синтаксис также будет работать:

CREATE TABLE ATEST (

ID BIGINT NOT NULL,

DATA VARCHAR(10),

CONSTRAINT PK_ATEST PRIMARY KEY(ID)

USING DESC INDEX IDX PK ATEST;

! ! !

ВНИМАНИЕ! Если вы создаете индекс DESCENDING для ограничения первичного или уникального ключа, вы должны указать USING DESC INDEX для всех ссылающихся на него внешних ключей.

. ! .

Добавление первичного ключа к существующей таблице

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

Обычно в первом скрипте мы объявляем таблицы и подтверждаем их создание:

CREATE TABLE ATABLE (

ID BIGINT NOT NULL,

ANOTHER_COLUMN VARCHAR (20),

< другие столбцы > ) ;

CREATE TABLE ANOTHERTABLE (

. . .

COMMIT;

ALTER TABLE ATABLE

ADD CONSTRAINT PK_ATABLE

PRIMARY KEY(ID);

ALTER TABLE ANOTHERTABLE…

и т.д.

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

Ограничения CHECK

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

! ! !

СОВЕТ. Ограничения CHECK применяются после выполнения триггеров «before». Используйте триггер, если вы хотите выполнить проверку и присвоить данным допустимые значения.

. ! .

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

CHECK(VALUE > 10)

В определении таблицы то же самое условие для столбца с именем ACOLUMN будет представлено как:

CHECK (ACOLUMN > 10)

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

! ! !

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

. ! .

Условие поиска может:

* проверять, что вводимое значение находится в указанном диапазоне;

* проверять, что значение присутствует в списке допустимых значений;

* сравнивать значение с константой, выражением или со значением данных другого столбца из этой же строки.

Замечания по использованию CHECK

Существуют определенные условия использования ограничений CHECK.

* Столбец может иметь только одно ограничение CHECK, хотя его логика может быть представлена как сложное условие поиска — одно ограничение, много условий.

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

* Ограничение CHECK не может ссылаться на домен. Синтаксис ограничения CHECK:

CHECK (<условие-поиска>);

<условие-поиска> =

<val> <operator> {<val> | {<выбор-одного>) }

| <val> [NOT] BETWEEN <val> AND <val>

| <val> [NOT] LIKE <val> [ESCAPE <val>]

| <val> [NOT] IN (<val> [, <val> …] | <список-выбора>)

| <val> IS [NOT] NULL

| <val> { [NOT] { = | < | > } |>=|<=}

{ ALL | SOME | ANY }(<список-выбора>)

| EXISTS (<выражение-выбора>)

| SINGULAR (<выражение-выбора>)

| <val> [NOT] CONTAINING <val>

| <val> [NOT] STARTING [WITH] <val>

| (<условие-поиска>)

| NOT <условие-поиска>

| <условие-поиска> OR <условие-поиска>

l <условие-поиска> AND <условие-поиска>

Диапазон возможностей при определении ограничений CHECK действительно весьма широк — теоретически в нем может быть использовано почти любое условие поиска. Для разработчика важно выбрать разумные и безопасные условия, т. к. они действуют для каждой операции INSERT и UPDATE для таблицы.

В части V данной книги описывается синтаксис установки различных стилей условия поиска.

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

CHECK (COL_1 > COL_2);

Проверка даст ошибку, если арифметическая проверка будет ошибочной или если любой из столбцов COL_1 или COL_2 имеет значение NULL. Следующая операция будет успешной:

INSERT INTO TABLE_1 (COL_1, COL_2) VALUES (6,5);

Ограничения UNIQUE

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

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

В Firebird 1.0.x атрибут NOT NULL должен быть применен для всех столбцов, с которыми оперирует ограничение UNIQUE.

Как и ограничение PRIMARY KEY, UNIQUE создает свой постоянный уникальный индекс для поддержания его правил. Правила именования ограничения и индекса соответствует тем же правилам поведения, применимым к другим ключам. Следующий пример isql иллюстрирует именование в Firebird 1.5:

SQL> CREATE TABLE TEST_UQ (

CON> ID BIGINT NOT NULL,

CON> DATA VARCHAR(10),

CON> DATA_ID BIGINT NOT NULL);

SQL> COMMIT;

SQL> ALTER TABLE TEST_UQ

CON>ADD CONSTRAINT PK_TEST_UQ PRIMARY KEY(ID),

CQN>ADD CONSTRAINT UQ1_DATA UNIQUE(DATA_ID) ;

SQL> COMMIT;

SQL> SHOW TABLE TEST_UQ;

ID BIGINT NOT NULL

DATA VARCHAR(10) NULLABLE

DATA_ID BIGINT NOT NULL

CONSTRAINT PK_TEST_UQ:

Primary key (ID)

CONSTRAINT UQ1_DATA:

Unique key (DATA_ID)

SQL> SHOW INDICES TEST_UQ;

PK_TEST_UQ UNIQUE INDEX ON TEST_UQ(ID)

UQ1_DATA UNIQUE INDEX ON TEST_UQ(DATA_ID)

SQL>

! ! !

ПРИМЕЧАНИЕ. Запомните следующее заклинание: индекс не является ключом. Вы можете создавать уникальные индексы (подробности см. в главе 18), но создание уникального индекса не создает уникального ключа. Если существует вероятность, что вам может понадобиться для использования уникально индексированный столбец или структура в качестве ключа, создайте вместо индекса ограничение.

. ! .

Использование внешних файлов в качестве таблиц

В текущем жаргоне SQL Firebird поддерживает внешние виртуальные таблицы (External Virtual Table, EVT). Файлы файловой системы в текстовом формате ASCII могут быть использованы в Firebird для чтения и манипулирования, как если бы они были таблицами, хотя и со значительными ограничениями, связанными с тем фактом, что они не являются внутренними объектами базы данных. Другие приложения могут обмениваться данными с базой данных Firebird, независимо от любых специальных механизмов преобразования. Внешние таблицы могут быть конвертированы во внутренние.

Предложение EXTERNAL FILE позволяет определять таблицы со структурой строки, отображаемой в «поля» фиксированной длины в «записях» (обычно разделенных символом перевода строки), которые размещаются во внешнем файле. Firebird может выбирать данные из файла и помещать данные в файл, как если бы это было обычной таблицей. При этом он не может выполнять операции изменения и удаления с внешними таблицами.

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

Синтаксис для CREATE TABLE…EXTERNAL FILE

Оператор CREATE TABLE для внешнего файла определяет как спецификацию внешнего файла (размещение и имя файла), так и характеристики столбцов Firebird, представляющих структуру хранимых записей.

CREATE TABLE внешняя-таблица

EXTERNAL FILE спецификация-файла (определение-столбца [, определение-столбца, …], [разделитель-строки-1 CHAR(l) [,разделитель-строки-2 CHAR(l)]]);

спецификация-файла — полный путь и имя файла для внешнего файла данных. Файл не должен существовать во время создания таблицы. При этом в Firebird 1.5 и выше оператор CREATE будет неудачным, если спецификация ссылается на несконфигуриро- ванное размещение внешнего файла. См. раздел «Организация защиты внешних файлов» далее в этой главе и разд. «Конфигурирование внешних размещений» главы 36.

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

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

* В Linux/UNIX это один символ перевода строки ASCII 10.

* В Windows это упорядоченная пара ASCII 13 (возврат каретки) и ASCII 10.

* В Mac OS это ASCII 10 и ASCII 13.

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

Ограничения и рекомендации

Организация защиты внешних файлов

Во всех версиях Firebird список каталогов должен быть сконфигурирован для ограничения размещений, где Firebird будет отыскивать или создавать внешние файлы. Параметры конфигурации ExternaiFiieAccess в firebird.conf (для серверов версии 1.5) или external_file_directory В ibconfig/isc_config (для версии 1.0.x) см. В главе 3. По умолчанию Firebird 1.5 инсталлируется без доступа к внешним файлам, в то время как версия 1.0.x дает открытый доступ к любому файлу файловой системы.

! ! !

ПРИМЕЧАНИЕ. Метод конфигурирования и возможности защиты системы от злоумышленных атак через доступ к внешним файлам различаются в разных версиях сервера.

. ! .

Формат внешних данных

Firebird сам создаст внешний файл, если не найдет его по месту, указанному в спецификации CREATE EXTERNAL TABLE ‘ <спецификация—файла>’. ЕСЛИ файл уже существует, ТО каждая его запись должна быть фиксированной длины, состоять из полей фиксированной длины, которая должна в точности соответствовать длине в байтах спецификациям столбцов в определении таблицы. Если приложение, создавшее файл, использует жесткие символы перевода строки (например, двухбайтовую последовательность возврат каретки и перевод строки в текстовых файлах Windows), включите в описание столбец для приспособления к этой последовательности. См. далее разд. «Символы конца строки».

Данные BLOB и массивы не могут быть считаны или записаны во внешний файл.

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

! ! !

СОВЕТ. Убедитесь, что вы выделили достаточный размер для размещения ваших данных. Для информации о размерах обратитесь к соответствующей главе в части III. Рисунок 8.1 описывает правила преобразования типов данных.

. ! .

CHAR в сравнении с VARCHAR

Использование VARCHAR в определении столбца внешнего строкового поля не рекомендуется, потому что он не является легко переносимым форматом:

<2-байтовое беззнаковое короткое х строка символьных байтов>

VARCHAR требует начального 2-байтового беззнакового числа для включения количества байтов строки, непосредственно за которым следует строка^[44]. Для многих внешних приложений может оказаться трудным или невозможным получить доступ к данным. По этой причине используйте CHAR вместо VARCHAR для строковых полей и убедитесь, что приложение переводит эту строку в полный размер.

Символы конца строки

Когда вы создаете таблицу, которая будет использована для импорта внешних данных, вы должны определить столбец, содержащий символ конца строки (End-Of-Line, EOL) или новой строки, если приложение, создающее этот файл, включает такой символ. Размер столбца должен быть достаточным, чтобы хранить конкретный системный символ EOL (обычно 1 или 2 байта). Для большинства версий UNIX это 1 байт. Для Windows и Macintosh — 2 байта.

Советы по добавлению непечатаемых символов

При добавлении данных во внешний файл внешняя функция ASCII_CHAR (десятичный- код-ASCII) из библиотеки функций ib udf может быть использована для передачи в

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

INSERT INTO MY_EXT_TABLE (

столбцы . . .,

CRIIF)

VALUES (

Значение-столбца. . .,

ASCII_CHAR(13) и ASCII_CHAR(10));

Альтернативой этому является создание таблицы специально для хранения непечатаемых символов, которые могут понадобиться вашим приложениям. Просто создайте текстовый файл на той же платформе, что и ваш сервер, используя редактор, который «отображает» непечатаемые символы. Откройте вашу «непечатаемую» таблицу, используя интерактивный инструмент, скопируйте и вставьте символы непосредственно в таблицу. Для операторов, выполняющих добавление во внешний файл, символ может быть получен с помощью подзапроса из таблицы^[45].

Операции

Только операции INSERT и SELECT могут быть выполнены над строками внешней таблицы. Попытки изменить или удалить строки вернут ошибки.

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

! ! !

СОВЕТ. Если вы хотите, чтобы ваша таблица находилась под управлением транзакции, создайте другую, внутреннюю таблицу Firebird и добавьте данные из внешней таблицы во внутреннюю.

. ! .

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

Импорт внешних файлов в таблицы Firebird

Для импорта внешних файлов в таблицы Firebird вначале убедитесь, что у вас установлены соответствующие условия доступа. См. разд. «Конфигурирование внешних размещений»главы 36 относительно параметра сервера ExternairiieAccess.

1. Создайте таблицу Firebird, которая позволит вам просматривать внешние данные. Объявите все столбцы как CHAR. Текстовый файл, содержащий данные, должен находиться на сервере. В следующем примере внешний файл существует в системе UNIX, следовательно, символ EOL занимает 1 байт.

CREATE TABLE EXT_TBL EXTERNAL FILE ‘file.txt’ (

FNAME CHAR (10) ,

LNAME CHAR(20),

HDATE CHAR(10),

NEWLINE CHAR(1));

COMMIT;

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

CREATE TABLE PERSONNEL (

FIRST_NAME VARCHAR(10),

LAST_NAME VARCHAR(20) ,

HIRE_DATE DATE,

NEW_LINE CHAR(1));

COMMIT;

3. Используя текстовый редактор или приложение, которое может выводить текст фиксированного формата, создайте и заполните внешний файл. Сделайте все записи одинаковой длины, заполняя неиспользуемые символы пробелами, и добавьте символ(n) EOL в конец каждой записи.

Количество символов в строке EOL зависит от платформы — см. предыдущие замечания.

Следующий пример иллюстрирует запись фиксированной длины в 41 символ, b представляет пробел, a n — EOL:

12345678901234567890123456789012345678901

fname. . . . . lname. . . . . . . hdate n

JamesbbbbbStarkeybbbbbbbbbbbbb2004-12-10n

ClaudiobbbValderramabbbbbbbbbb2003-10-01n

4. Оператор SELECT для таблицы EXT_TLB возвращает записи из внешнего файла:

SELECT FNAME, LNAME, HDATE FROM EXT_TBL;

FNAME	LNAME	HDATE
=====	=====	=====
James	Starkey	2004-12-10
Claudio	Valderrama	2003-10-01

5. Добавьте данные в таблицу назначения:

INSERT INTO PERSONNAL

SELECT FNAME, LNAME, CAST( HDATE AS DATE),

NEWLINE FROM EXT_TBL;

COMMIT;

! ! !

ПРИМЕЧАНИЕ. Если вы пытаетесь обратиться к файлу, в то время как он еще открыт другим приложением, эта попытка даст сбой. Обратное также верно, и более того: когда ваше приложение откроет файл как таблицу, он будет недоступен для других приложений, пока ваше приложение не отсоединится от базы данных^[46].

. ! .

Теперь, когда вы выполните SELECT для PERSONNEL, данные из вашей внешней таблицы появятся в конвертированной форме:

SELECT FIRST_NAME, LAST_NAME, HIRE_DATE

FROM PERSONNEL;

FIRST NAME LAST NAME HIRE DATE

James Starkey 10-DEC-2004

Claudio Valderrama 01-OCT-2003

Экспорт таблиц Firebird во внешние файлы

Вернемся к примеру в предыдущем разделе. Шаги по экспорту данных в нашу внешнюю таблицу похожи:

1. Откройте внешний файл в текстовом редакторе и удалите в нем все. Выйдите из текстового редактора и снова выполните запрос SELECT к таблице EXT_TBL. Она должна быть пустой.

2. Используйте оператор INSERT для копирования записей Firebird из PERSONNEL во внешний файл file.txt:

INSERT INTO EXT_TBL

SELECT FIRST_NAME, LAST_NAME,

cast (HIRE_DATE AS VARCHAR(ll),

ASCII_CHAR(10) FROM PERSONNEL

WHERE FIRST_NAME LIKE ‘Clau%’;

3. Теперь выберите данные из внешней таблицы:

SELECT FNAME, LNAME, HDATE FROM EXT_TBL;

FNAME LNAME HDATE

Claudio Valderrama 01-OCT-2004

! ! !

СОВЕТ. Внешняя функция ASCII_CHAR находится в библиотеке ib_udf в каталоге /UDF каталога инсталляции Firebird. Ее объявление может быть найдено в скрипте ib_udf.sql. Об использовании внешних функций см. главу 21.

. ! .

Конвертирование внешних таблиц во внутренние

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

Подробную информацию см. в главе 38.

Изменение таблиц

Оператор ALTER TABLE используется для изменения структуры таблицы: добавления, изменения или удаления столбцов или ограничений. При необходимости один оператор может выполнять несколько изменений. Для выполнения ALTER TABLE вы должны быть соединены с базой данных как создатель таблицы (ее владелец), пользователь SYSDBA или (в POSIX) как Суперпользователь.

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

ALTER TRIGGER имя-триггера ACTIVE | INACTIVE

! ! !

СОВЕТ. Запланируйте выполнение резервного копирования и восстановления после изменений структур таблиц, если база данных содержит данные. Когда изменяется таблица или столбец, Firebird не выполняет преобразования измененного формата. Для упрощения оперативного изменения метаданных он сохраняет новое описание формата и откладывает преобразование, пока данные нужны. Это могло бы оказать непредвиденное влияние на работу пользователей.

. ! .

Подготовка к выполнению ALTER TABLE

Перед модификацией или удалением столбцов или атрибутов в таблице вам нужно выполнить три дела:

1. Убедитесь, что вы имеете соответствующие привилегии к базе данных.

2. Сохраните существующие данные.

3. Удалите любые ограничения зависимостей в столбце.

Изменение столбцов в таблице

Существующие столбцы в таблице могут быть изменены в нескольких отношениях, а именно:

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

* столбец может быть «перенесен» на другую позицию в системе упорядочивания столбцов слева направо;

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

Синтаксис

Используйте следующий синтаксис для ALTER TABLE:

ALTER TABLE таблица

ALTER [COLUMN] имя-простого-столбца изменение;

изменение = новое-имя-столбца | новый-тип-столбца | новая-позиция-столбца

новое-имя-столбца = ТО имя-простого-столбца

новый-тип-столбца = TYPE тип-данных-или-домен

новая-позиция-столбца = POSITION целое

! ! !

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

. ! .

Примеры

Здесь мы изменяем имя столбца с EMP_NO на EMP_NUM:

ALTER TABLE EMPLOYEE

ALTER COLUMN EMP_NO TO EMP_NUM;

/* ключевое слово COLUMN необязательно */

Теперь изменяется позиция столбца:

ALTER TABLE EMPLOYEE

ALTER COLUMN EMP_NUM POSITION 4;

В этот раз тип данных EMP_NUM заменяется с INTEGER на VARCHAR (20):

ALTER TABLE EMPLOYEE

ALTER COLUMN EMP_NUM TYPE VARCHAR(20) ;

Ограничения при изменении типа данных

Firebird не позволит вам изменить тип данных столбца или домена, в результате чего могут потеряться данные.

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

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

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

* Столбцы массивов и BLOB не могут быть преобразованы.

! ! !

ВНИМАНИЕ! Любые изменения определения полей могут потребовать пересоздания индексов.

. ! .

Удаление столбцов

Владелец таблицы может использовать ALTER TABLE для удаления определения столбца и его данных из таблицы. Удаление столбца приводит к потере всех хранимых в нем данных. Удаление приводит к немедленному эффекту, независимо от других транзакций, работающих с таблицей. В этом случае другая транзакция продолжается без прерывания, a Firebird откладывает удаление до освобождения таблицы.

До удаления столбца учтите условия, при которых невозможно будет выполнить удаление. Удаление будет ошибочным, если столбец:

* является частью ограничения UNIQUE, PRIMARY KEY или FOREIGN KEY;

* включен в ограничение CHECK (это могут быть ограничения CHECK на уровне таблицы для основанного на домене столбца в дополнение к ограничению его домена);

* используется в просмотре, триггере или хранимой процедуре.

Зависимости должны быть удалены до удаления столбца. Столбцы, включенные в состав ограничений PRIMARY KEY и UNIQUE, не могут быть удалены, если на них есть ссылки в ограничениях FOREIGN KEY. В этом случае удалите ограничение FOREIGN KEY до удаления ограничения PRIMARY KEY или UNIQUE. После этого удаляйте столбец.

Синтаксис:

ALTER TABLE имя-таблицы DROP имя-столбца [, имя-столбца …];

Например, следующий оператор удаляет столбец JOB_GRADE из таблицы EMPLOYEE:

ALTER TABLE EMPLOYEE DROP JOB_GRADE;

Удаление нескольких столбцов в одном операторе:

ALTER TABLE EMPLOYEE

DROP JOB_GRADE,

DROP FULL NAME;

Удаление ограничений

Необходимо выполнять удаление ограничений в правильной последовательности, если ограничения PRIMARY KEY и CHECK имеют зависимости.

! ! !

СОВЕТ. Для поиска имен ограничений может оказаться полезным выполнение четырех системных просмотров, определенных в скрипте system_views.sql, представленном в приложении 9.

. ! .

Ограничения UNIQUE KEY и PRIMARY KEY

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

. . .

FK_DATA_ID FOREIGN KEY DATA_ID

REFERENCES TEST_UQ (DATA_I D) ;

Если ключ, на который имеются ссылки, является первичным ключом, то имя столбца первичного ключа является необязательным в объявлениях внешнего ключа и часто опускается. Например, посмотрите на базу данных ../samples/employee.gdb:

…TABLE PROJECT (

. . . ,

TEAM_CONSTRT FOREIGN KEY(TEAM_LEADER)

REFERENCES EMPLOYEE );

Удаление ограничения внешнего ключа простое:

ALTER TABLE PROJECT

DROP CONSTRAINT TEAM_CONSTRT;

COMMIT;

После этого становится возможным удаление ограничения первичного ключа для столбца EMP_NO таблицы EMPLOYEE:

ALTER TABLE EMPLOYEE

DROP CONSTRAINT EMP_NO_CONSTRT ;

Ограничения CHECK

Любые условия CHECK, которые были добавлены в процессе определения таблицы, могут быть удалены без каких-либо осложнений. Условия CHECK, наследуемые от домена, являются более проблематичными. Для освобождения от ограничений домена необходимо выполнить операцию ALTER TABLE ALTER COLUMN … TYPE для изменения типа данных столбца или указания другого домена.

Добавление столбца

Один или более столбцов можно добавить в таблицу в одном операторе при использовании предложения ADD. Каждое предложение ADD включает полное определение столбца. Используется тот же самый синтаксис, что и при определении столбца в операторе CREATE TABLE. Предложения ADD отделяются друг от друга запятыми.

Синтаксис:

ALTER TABLE таблица ADD <определение-столбца>

<определение-столбца> = столбец

{<тип данных> | [COMPUTED [BY] (<выражение>) | домен}

[DEFAULT {литерал NULL | USER} ]

[NOT NULL] [<ограничение-столбца>]

[COLLATE порядок-сортировки]

<ограничение-столбца> = [CONSTRAINT ограничение]

<определение -ограничения> [< ограничение-столбца>]

< определение -ограничения>=

PRIMARY KEY

| UNIQUE

| CHECK (<условие-поиска>)

| REFERENCES другая-таблица [(другой-столбец [,другой-столбец…])]

[ON DELETE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]

[ON UPDATE {NO ACTION|CASCADE | SET DEFAULT | SET NULL}]

Следующий оператор добавляет столбец EMP_NO в таблицу EMPLOYEE С использованием домена EMPNO:

ALTER TABLE EMPLOYEE ADD EMP_NO EMPNO NOT NULL;

Пример

Здесь мы добавляем два столбца EMAIL_ID и LEAVE_STATUS в таблицу EMPLOYEE:

ALTER TABLE EMPLOYEE

ADD EMAIL_ID VARCHAR(10) NOT NULL,

ADD LEAVE_STATUS DEFAULT 10 INTEGER NOT NULL;

Включение ограничений целостности

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

ALTER TABLE EMPLOYEE

ADD EMAIL_ID VARCHAR(10) NOT NULL,

ADD LEAVE_STATUS DEFAULT 10 INTEGER NOT NULL,

ADD CONSTRAINT UQ_EMAIL_ID UNIQUE(EMAIL_ID);

или

ALTER TABLE EMPLOYEE

ADD EMAIL_ID VARCHAR(IO) NOT NOLL UNIQUE,

ADD LEAVE_STATUS DEFAULT 10 INTEGER NOT NULL;

Добавление новых ограничений таблицы

Предложение ADD CONSTRAINT может быть использовано для добавления ограничений на уровне таблицы для нового или существующего столбца.

Синтаксис:

ALTER TABLE имя ADD [CONSTRAINT ограничение] <ограничение-таблицы>;

где ограничение-таблицы- может быть ограничением PRIMARY KEY, FOREIGN KEY, UNIQUE или CHECK. Фраза CONSTRAINT ограничение может быть опущена, если вам не нужно имя ограничения.

Пример

Для добавления ограничения UNIQUE в таблицу EMPLOYEE вы можете использовать следующий оператор:

ALTER TABLE EMPLOYEE

ADD CONSTRAINT UQ_PHONE_EXT UNIQUE(PHONE_EXT);

Когда недостаточно ALTER TABLE

Иногда бывает нужным произвести изменение столбца, которое нельзя совершить с помощью ALTER TABLE. Примером может быть случай, когда столбец, хранящий международные элементы языка, имеет набор символов NONE, который нужно заменить на другой набор символов, чтобы исправить ошибку проектирования, или телефонный номер, определенный вначале кем-то как целое, нужно заменить на 18-символьный столбец.

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

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

1. Добавьте в таблицу временный столбец с теми атрибутами, которые вам нужны.

ALTER TABLE PERSONNEL

ADD TEMP_COL VARCHAR (18) ;

COMMIT;

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

UPDATE PERSONNEL

SET TEMP_COL = CAST(TEL_NUMBER AS VARCHAR(18))

WHERE TEL_NUMBER IS NOT NULL;

COMMIT;

3. После проверки того, что данные во временном столбце были изменены, как планировалось, удалите старый столбец.

ALTER TABLE PERSONNEL DROP TEL_NUMBER;

4. Создайте «новый» столбец, с тем же именем, как и тот, который вы только что удалили, и с теми же атрибутами, что и у временного столбца.

ALTER TABLE PERSONNEL

ADD TEL_NUMBER VARCHAR (18);

5. Скопируйте данные во вновь созданный столбец.

UPDATE PERSONNEL

SET TEL_NOMBER = TEMP_COL WHERE TEMP_COL IS NOT NULL;

COMMIT;

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

ALTER TABLE PERSONNEL

DROP COLUMN TEMP_COL,

ALTER TEL_NUMBER POSITION 6;

COMMIT;

Удаление таблицы

DROP TABLE

Используйте оператор DROP TABLE для удаления таблицы и ее данных из базы данных.

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

DROP TABLE имя;

Следующий оператор удаляет таблицу PERSONNEL:

DROP TABLE PERSONNEL;

RECREATE TABLE

Иногда бывает нужно удалить таблицу и снова создать ее «с нуля». Для таких случаев Firebird имеет оператор RECREATE TABLE, который делает следующее:

* удаляет существующую таблицу и все принадлежащие ей объекты;

* подтверждает изменения;

* создает новую таблицу в соответствии с указанной спецификацией.

Синтаксис

Синтаксис RECREATE TABLE идентичен синтаксису оператора CREATE TABLE. Просто замените ключевое слово CREATE на RECREATE.

! ! !

ВНИМАНИЕ! Убедитесь, что вы сохранили исходные тексты триггеров, ключей и индексов этой таблицы до выполнения запроса RECREATE TABLE!

. ! .

Ограничения и рекомендации

Если при выполнении оператора DROP или RECREATE таблица находится в использовании, запрос не будет выполнен, появится сообщение «Object xxxxx is in use» (Объект xxxxx используется).

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

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

Временные таблицы

Firebird не поддерживает временные таблицы, которые управляются системой. Здесь они меньше нужны, чем в других СУБД. Например, у Firebird есть возможность получать виртуальные таблицы напрямую через хранимую процедуру, написанную с использованием специального синтаксиса. Более подробно об этом см. разд. «Хранимые процедуры выбора» в главах 29 и 30.

Постоянные «временные» таблицы

Популярная модель хранения временных данных для доступа приложений — определить постоянную структуру данных, которая включает «идентификатор сессии» или «идентификатор пакета», получающие значение от генератора, или, в Firebird 1.5,

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

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

! ! !

СОВЕТ. Временные таблицы, скорее всего, появятся в следующем релизе Firebird.

. ! .

Пора дальше

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

ГЛАВА 17. Ссылочная целостность данных.

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

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

* Бомбоубежище: формальные ссылочные ограничения — особенно при разумном использовании других ограничений — станут надежным бомбоубежищем бизнес- правил вашей базы данных от ошибок приложений, независимо от их источника. Это будет в особенности важным, когда вы начнете устанавливать ваши системы на сайты, где неквалифицированный или частично квалифицированный персонал будет получать доступ к базе данных через утилиты сторонних организаций.

* Скорость запросов: индексы, автоматически созданные для ограничений ссылочной целостности, увеличат скорость операций соединения (join)^[47].

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

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

Терминология

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

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

Ограничение FOREIGN KEY

Внешний ключ — это столбец или набор столбцов в одной таблице, которые в точности соответствуют столбцу или набору столбцов, определенных как ограничение PRIMARY KEY или ONIQUE в другой таблице. В своей простейшей форме внешний ключ реализует необязательное отношение один-ко-многим.

! ! !

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

этой главе.

. ! .

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

Рис. 17.1. Модель объект-отношение

Если мы реализуем такую модель между двумя таблицами PARENT и CHILD, то строки в таблице CHILD зависят от существования связанной строки из PARENT. Ограничение FOREIGN KEY в Firebird осуществляет это отношение следующими способами:

* требуется, чтобы значение столбца внешнего ключа в таблице CHILD (CHILD.PARENT ID) могло быть связано с соответствующим значением уникального ключа (в нашем случае, первичного ключа) в таблице PARENT (PARENT, ID);

* по умолчанию запрещено удаление строки PARENT или изменение значения уникального ключа, если существуют зависимые строки в CHILD;

* должно быть реализовано отношение, которое предполагалось во время создания ссылки или когда оно в последний раз изменялось^[48];

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

Реализация ограничения

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

Родительская структура

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

CREATE TABLE PARENT (

ID BIGINT NOT NULL,

DATA VARCHAR(20),

CONSTRAINT PK_PARENT PRIMARY KEY(ID));

COMMIT;

Дочерняя структура

В дочернюю структуру нам нужно включить столбец PARENT_ID, который в точности соответствует первичному ключу родительской таблицы по типу и размеру (а также по порядку столбцов, если связь выполняется по нескольким столбцам):

CREATE TABLE CHILD (

ID BIGINT NOT NULL,

CHILD_DATA VARCHAR(20),

PARENT_ID BIGINT,

CONSTRAINT PK_CHILD PRIMARY KEY(ID));

COMMIT;

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

Синтаксис определения FOREIGN KEY

Синтаксис определения ссылочной целостности следующий:

FOREIGN KEY (столбец [, столбец …])

REFERENCES (родительская-таблица [, столбец …])

[USING [ASC | DESC] INDEX имя-индекса] /* добавлено в версии 1.5 */

[ON DELETE {NO ACTION | CASCADE | SET NULL | SET DEFAULT}]

[ON UPDATE {NO ACTION | CASCADE | SET NULL | SET DEFAULT}]

Определим наш внешний ключ:

ALTER TABLE CHILD

ADD CONSTRAINT FK_CHILD_PARENT

FOREIGN KEY(PARENT_ID)

REFERENCES PARENT(ID);

/* также допустимо REFERENCES PARENT, поскольку ID является первичным ключом таблицы PARENT */

Firebird сохраняет ограничение FK_CHILD_PARENT и создает обычный индекс для столбца (столбцов), перечисленных в качестве аргументов FOREIGN KEY. В Firebird этот индекс будет также назван FK_CHILD_PARENT, если вы не использовали необязательное предложение USING для задания другого имени индекса. В Firebird 1.0.x индекс будет иметь имя INTEG_NN (где NN — некоторое число).

! ! !

ВНИМАНИЕ! Если вы указали убывающий индекс для ограничения первичного или уникального ключа, вы также должны указать USING DESCENDING INDEX для каждого ссылающегося на него внешнего ключа.

. ! .

Наши две таблицы теперь связаны огpаничением формальной ссылочной целостности. Мы можем добавлять новые строки в таблицу PARENT без каких-либо огpаничений:

INSERT INTO PARENT (ID, DATA)

VALUES (1, ‘Pareпt No, 1’);

При этом существует ограничение для CНILD. Мы можем выполнить следующее:

INSERT INTO CHILD (ID, CHILD_DATA)

VALUES (1, ‘Child No. 1’);

Поскольку допускающий пустое значение столбец PARENT_ID отсутствует в списке столбцов, в нем будет сохранено значение NULL. Это допускается правилами целостности по умолчанию. Такая строка будет зависшей (или осиротевшей, orphan).

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

INSERT INTO CHILD(ID, CHILD_DATA, PARENT_ID)

VALUES (2, ‘child No, 2’, 2);

ISC ERROR CODE:335544466

ISC ERROR MESSAGE:

violation of FOREIGN KEY constraint «FK_CHILD_PARENT» on table «CHILD» (нарушение ограничения «FK_CHILD_PARENT» для внешнего ключа таблицы CHILD)

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

Оба следующих действия допустимы:

UPDATE CHILD

SET PARENT_ID = 1

WHERE ID = 1;

COMMIT;

/**/

INSERT INTO CHILD (ID, CHILD_DATA, PARENT_ID)

VALUES (2, ‘Child No.2’, 1) ;

COMMIT;

Теперь строка из PARENT со значением ID = 1 имеет две дочерние строки. Это классическая структура главная-подчиненная — простая реализация отношения один-ко- многим. Для защиты целостности данного отношения правила по умолчанию не позволят выполнить следующее:

DELETE FROM PARENT WHERE ID = 1;

Действия триггеров по изменению правил целостности

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

[ON DELETE {NO ACTION | CASCADE | SET NULL | SET DEFAULT}]

[ON UPDATE {NO ACTION | CASCADE | SET NULL | SET DEFAULT}]

Автоматические действия триггеров

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

Семантика действий триггера

NO ACTION

Поскольку это действие триггера по умолчанию, ключевое слово может быть — и часто бывает — опущено^[49]. Операция DML над родительским первичным ключом не изменяет внешний ключ и потенциально может привести к ошибке операции над родительской таблицей.

ON UPDATE CASCADE

В зависимой таблице внешний ключ, соответствующий старому значению первичного ключа, изменяется на новое значение первичного ключа.

ON DELETE CASCADE

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

SET NULL

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

SET DEFAULT

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

* Используется значение по умолчанию, которое существовало в момент создания ограничения FOREIGN KEY. Если значение по умолчанию у столбца будет изменено позже, то значение по умолчанию для действия SET DEFAULT В определении внешнего ключа не будет изменено на новое значение — оно сохранит прежнее значение.

* Если никакое значение по умолчанию не было явно установлено для столбца, то неявным значением по умолчанию будет NULL. В этом случае поведение при SET DEFAULT будет тем же самым, что и при SET NULL.

* Если значение по умолчанию для столбца внешнего ключа — такое значение, которое не имеет соответствующего значения первичного ключа в родительской таблице, то действие триггера приведет к нарушению ограничения.

Взаимодействие ограничений

Комбинируя формальное ссылочное ограничение с другими ограничениями целостности (см. главу 16), можно реализовать большинство (если не все) бизнес-правил с высокой степенью точности. Например, ограничение столбца NOT NULL будет корректировать действия и предотвратит появление зависших строк, если это необходимо, тогда как столбец внешнего ключа, который допускает пустые значения, может быть использован для реализации специальных структур данных, таких как деревья (см. разд. «Ссылающиеся на себя отношения»).

! ! !

СОВЕТ. Если вам нужно сделать столбец вашего внешнего ключа NOT NULL, создайте «фиктивную» строку родительской таблицы с неиспользуемым значением ключа, например, 0 или -1. Используйте действие SET DEFAULT для эмуляции поведения SET NULL, чтобы сделать значением по умолчанию фиктивное значение ключа.

. ! .

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

Триггеры действий пользователя

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

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

! ! !

СОВЕТ. Селективность индекса довольно подробно обсуждается в главе 18. Если эта тема для вас новая, то это может вас заставить основательно разобраться в данном вопросе до принятия решения реализовывать отношение один- ко-многим в вашей модели данных с использованием формальных ограничений целостности «только потому, что я могу».

. ! .

При написании пользовательских ссылочных триггеров вы должны убедиться, что ваши собственные триггеры или ваше приложение будут поддерживать ссылочную целостность при изменении данных в любом ключе. Триггеры более безопасны, чем код приложений, поскольку они централизуют правила целостности данных в базе данных и поддерживают их для всех типов доступа к данным, будь то программы, утилиты, скрипты или приложение серверного уровня^[50].

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

Таблицы соответствия и ваша модель данных

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

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

В реализованных базах данных такое отношение не является отношением главная- подчиненная, или родитель-потомок, потому что значение первичного ключа у набора соответствия требует одного и только одного столбца. Это не влияет на другие отношения, в которых участвует этот «псевдопотомок».

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

Посмотрите на следующий пример отношения соответствия, являющийся наследием конвертирования очень плохо спроектированного приложения для Access в Firebird. Клиентские приложения Access могут выполнять изящные действия с целыми таблицами, которые позволяют дилетантам создавать приложения RAD. Эта таблица была использована в визуальном управляющем элементе, который мог отображать таблицу и «перемещать» значение в другую таблицу при щелчке по кнопке.

CREATE TABLE COLORS (COLOR CHARACTER(20) NOT NULL PRIMARY KEY);

Фрагмент DDL одной из таблиц, которая использует COLORS В качестве таблицы соответствия:

CREATE TABLE STOCK_ITEM (

. . .

COLOR CHARACTER(20) DEFAULT ‘NEUTRAL’,

. . .

CONSTRAINT FK_COLOR FOREIGN KEY (COLOR)

REFERENCES COLORS(COLOR)

ON UPDATE CASCADE

ON DELETE SET DEFAULT;

Существует множество проблем с этим ключом. Во-первых, таблица COLORS была доступна покупателям товаров для ее редактирования, как они считали нужным. Изменения выполнялись каскадно по всей системе всякий раз, когда новые элементы добавлялись в ассортимент. Удаления часто убирают информацию о цвете в относительно небольшом количестве элементов, в которых она используется. Хуже того, основная масса элементов в системе имела один цвет ‘NEUTRAL’, в результате чего индекс внешнего ключа ухудшал выполнение запросов.

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

CREATE TABLE COLORS (

ID INTEGER NOT NULL PRIMARY KEY, /* or UNIQUE */

COLOR CHARACTER(20));

COMMIT;

INSERT INTO COLORS (ID, COLOR)

VALUES (0, ‘NEUTRAL’);

COMMIT;

CREATE TABLE STOCK_ITEM (

. . .

COLOR INTEGER DEFAULT 0,

. . .);

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

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

Привилегии на ссылки

Firebird поддерживает безопасность SQL для всех объектов в базе данных. Каждый пользователь, за исключением владельца базы данных, пользователя SYSDBA или с системными привилегиями root, должен получить (при использовании GRANT) необходимые привилегии доступа к объекту. Привилегии SQL очень подробно обсуждаются в главе 3 7.

Тем не менее одна привилегия очень важна при проектировании инфраструктуры ссылочной целостности — привилегия REFERENCES. ЕСЛИ родительская и дочерняя таблицы имеют разных владельцев, привилегия GRANT REFERENCES может оказаться необходимой для предоставления пользователям достаточных полномочий для действий ссылочного ограничения.

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

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

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

! ! !

СОВЕТ. Не делайте это сложнее, чем оно должно быть. Если нет никакого требования отменять привилегии чтения для таблицы, на которую осуществляются ссылки, то передайте привилегию REFERENCES К ней для всех (PUBLIC).

. ! .

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

Обработка других видов отношений

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

* Один-к-одному.

* Многие-ко-многим.

* Ссылающееся на себя отношение один-ко-многим (вложенные или древовидные отношения).

* Обязательные варианты любых форм отношений.

Отношение один-к-одному

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

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

Обычным является дублирование столбца (столбцов) первичного ключа в подчиненной таблице в качестве внешнего ключа для «родительской».

CREATE TABLE PARENT_PEER (

ID INTEGER NOT NULL,

MORE_DATA VARCHAR(10),

CONSTRAINT PK_PARENT_PEER PRIMARY KEY(ID),

CONSTRAINT FK_PARENT_PEER_PARENT

FOREIGN KEY (ID) REFERENCES PARENT);

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

В версиях 1.0.x и 1.5 оптимизатор игнорирует первичный индекс подчиненной таблицы. Например:

SELECT PARENT.ID, PARENT_PEER.ID,

PARENT.DATA, PARENT_PEER.MORE_DATA

FROM PARENT JOIN PARENT_PEER

ON PARENT.ID = PARENT_PEER.ID;

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

PLAN JOIN (PARENT_PEER NATURAL, PARENT INDEX (PK_PARENT) )

Влияние на производительность «разреженного» ключа (такого, какой использован в этом примере) не может быть сильным. В случае составного ключа эффект может быть значительным, особенно в случае множественных соединений, включающих отношения один-к-одному. Следует рассмотреть использование суррогатного ключа в структурах один-к-одному^[51].

! ! !

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

. ! .

Отношение многие-ко-многим

В этом интересном случае, показанном на рис. 17.2, наша модель данных показывает, что каждая строка в таблице TableA может иметь отношения со множеством строк таблицы TableB, и в то же время каждая строка в TableB может иметь множественные отношения со строками В TableA.

Рис. 17.2. Отношения многие-ко-многим

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

Работа с циклическими ссылками

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

CREATE TABLE TABLEA (

ID INTEGER NOT NULL,

. . .,

CONSTRAINT PK_TABLEA PRIMARY KEY (ID));

COMMIT;

CREATE TABLE TABLEB (

ID INTEGER NOT NULL,

. . . ,

CONSTRAINT PK_TABLEB PRIMARY KEY (ID));

COMMIT;

ALTER TABLE TABLEA

ADD CONSTRAINT FK_TABLEA_TABLEB

FOREIGN KEY(IDB) REFERENCES TABLEB(ID);

COMMIT;

ALTER TABLE TABLEB

ADD CONSTRAINT FK_TABLEB_TABLEA

FOREIGN KEY(IDA) REFERENCES TABLEA(ID);

COMMIT;

Вот этот прием:

INSERT INTO TABLEB(ID)

VALUES(1);

/* создает строку со значением NULL в столбце IDB */

COMMIT;

INSERT INTO TABLEA(ID, IDB)

VALUES(22, 1);

/* связывает с только что созданной строкой в TABLEB */

COMMIT;

UPDATE TABLEB

SET IDA = 22 WHERE ID = 1;

COMMIT;

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

! ! !

ВНИМАНИЕ! На практике таблицы с отношением многие-ко-многим, реализованным циклически, очень сложно представить в приложениях с графическим интерфейсом.

. ! .

Использование таблиц пересечения

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

Такая реализация проста для использования в приложениях. Триггеры BEFORE INSERT (до добавления) и BEFORE UPDATE (до изменения) для обеих таблиц выполняют при необходимости добавление строки в таблицу пересечения. Рис. 17.3 иллюстрирует, как таблица пересечения реализует отношение многие-ко-многим.

Рис. 17.3. Реализация отношения многие-ко-многим

Вот как это может быть реализовано:

CREATE TABLE TABLEA (

ID INTEGER NOT NULL,

. . . ,

CONSTRAINT PK_TABLEA PRIMARY KEY (ID));

COMMIT;

CREATE TABLE TABLEB (

ID INTEGER NOT NULL,

CONSTRAINT PK_TABLEB PRIMARY KEY (ID));

COMMIT;

/**/

CREATE TABLE TABLEA_TABLEB (

IDA INTEGER NOT NULL,

IDB INTEGER NOT NULL,

CONSTRAINT PK_TABLEA_TABLEB

PRIMARY KEY (IDA, IDB));

COMMIT;

ALTER TABLE TABLEA_TABLEB

ADD CONSTRAINT FK_TABLEA FOREIGN KEY (IDA)

REFERENCES TABLEA,

ADD CONSTRAINT FK_TABLEB FOREIGN KEY (IDB)

REFERENCES TABLEB;

COMMIT;

Ссылающиеся на себя отношения

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

Рис. 17.4. Ссылающееся на себя отношение

Это классическая древовидная иерархия, где любой элемент (строка) может быть и родителем, и потомком — т. е. строка может иметь зависящие от нее «дочерние» строки и в то же время она может зависеть от другого элемента (строки). Здесь требуется ограничение CHECK или триггеры BEFORE INSERT (до добавления) и BEFORE UPDATE (до изменения) для проверки того, чтобы PARENT_ID никогда бы не указывал сам на себя.

Если ваши бизнес-правила требуют, чтобы родитель существовал до того, как будет добавляться потомок, вам понадобится использование значения (например, -I) в качестве корневого узла в этой древовидной структуре. Тогда PARENT ID должен быть создан с NOT NULL и значением по умолчанию, равным выбранному вами значению корневого узла. Альтернативой является разрешение для PARENT ID пустого значения, как в следующем примере, и использование NULL в качестве значения корня.

Вообще пользовательские триггеры BEFORE INSERT (до добавления) и BEFORE UPDATE (до изменения) потребуются для деревьев, имеющих более двух уровней вложенности. Для согласованности деревьев с корневым узлом NULL важно обеспечить такие действия ограничений, которые бы не создавали случайно зависшие дочерние строки.

CREATE TABLE PARENT_CHILD (

ID INTEGER NOT NULL,

PARENT_ID INTEGER

CHECK (PARENT_ID <> ID));

COMMIT;

ALTER TABLE PARENT_CHILD

ADD CONSTRAINT PK_PARENT

PRIMARY KEY(ID);

COMMIT;

ALTER TABLE PARENT_CHILD

ADD CONSTRAINT FK_CHILD_PARENT

FOREIGN KEY(PARENT_ID)

REFERENCES PARENT_CHILD(ID);

О древовидных структурах

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

границы стандарта SQL. К сожалению, она выходит за рамки данной книги. Некоторые интересные решения см. в «SQL for Smarties», 2nd Edition by Joe Celko (Morgan Kaufmann, 1999).

Обязательные отношения

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

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

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

Подробности написания триггеров, а также пример триггера для поддержания обязательного отношения см. в главе 31.

Ошибка «объект находится в использовании»

Исключение «object is in use» (объект находится в использовании) заслуживает внимания в контексте применения ограничений ссылочной целостности, поскольку является постоянным источником огорчений для новичков. Firebird не позволяет добавлять или удалять ссылочное ограничение FOREIGN KEY, если транзакция использует любую из участвующих таблиц.

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

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

! ! !

СОВЕТ. Если вы имеете исключительный доступ, а исключение все равно появляется, то вполне возможно, что объект используете именно вы. Если вы работаете с утилитой администратора, где браузер данных сфокусирован на одной из ваших таблиц, то этот объект находится в использовании!

. ! .

Пора дальше

Firebird использует индексы для поддержания ссылочной целостности. При этом индексы играют такую же важную роль в оптимизации производительности при операциях поиска и упорядочения, требуемых для запросов и для изменения данных. В следующей главе мы рассмотрим в полном объеме вопросы проектирования, создания и тестирования индексов. Глава заканчивается специальным разделом, посвященным оптимизации индексов с использованием Firebird-утилиты получения статистики по индексам gstat.

ГЛАВА 18. Индексы.

Индексы являются атрибутами таблицы, которые могут содержать один столбец или группу столбцов для ускорения поиска строк.

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

Ограничения

Firebird допускает до 256 определенных пользователем индексов на одну таблицу в версии 1.5 и выше, и 64 в более ранних релизах. Однако это теоретические ограничения, которые могут быть скорректированы за счет размера страницы и фактического размера на диске данных описания индекса в корневой странице индекса. Вы не сможете хранить 256 индексов в базе данных с размером страницы менее 16 Кбайт. На корневой странице индекса каждому индексу нужен 31 байт для его идентификатора, место для описания каждого сегмента (столбца), включенного в состав индекса, и несколько байтов для хранения указателя на первую страницу индекса. Даже страница в 16 Кбайт может не оказаться способной хранить 256 индексов, если в базе данных существует немало составных индексов.

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

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

* интернациональные наборы символов, использующие несколько байт на символ;

* интернациональные наборы символов со сложными парами верхний/нижний регистры и/или сложным словарем правил сортировки;

* использование недвоичных порядков сортировки;

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

Другими словами, использование любого набора символов за исключением NONE будет влиять на ваши решения по проектированию индексов — особенно на использование составных индексов. Это плохие новости. Хорошие новости- Firebird правильно использует индексы из одного столбца в многостолбцовых поисках и сортировках, сокращая потребность в многостолбцовых индексах, которые вы могли использовать в других СУБД.

Автоматические индексы в сравнении с определенными пользователем индексами

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

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

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

Импорт существующих индексов

Не импортируйте «первичные индексы» таблиц при миграции из другой СУБД. Есть две важные причины отказаться от таких индексов.

* Многие существующие системы используют иерархические структуры индексов для реализации ссылочной целостности. Базы данных SQL не используют подобную логику для реализации ссылочной целостности. Такие индексы обычно влияют на логику оптимизатора Firebird.

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

Направленные индексы

Направление сортировки индексов в Firebird является важным. Ошибочно было бы предполагать, что один и тот же индекс может быть использован для сортировки или поиска «в обоих направлениях» — от меньшего к большему и от большего к меньшему. В практике индексы ASC (ASCENDING, в возрастающем порядке) помогут в поиске относительно небольшого количества значений, в то время как индексы DESC (DESCENDING, В убывающем порядке) будут полезными при большом количестве значений.

Если автоматический индекс ASC (по умолчанию), то не будет проблем, если вам нужно определить индекс DESC, использующий тот же столбец (столбцы). Обратное также верно: в Firebird 1.5 и выше вы можете выбрать для автоматически создаваемых индексов убывающий порядок. Оптимизатор не «расстроится», если вы также создадите возрастающий индекс для тех же столбцов.

Планы запросов

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

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

* По умолчанию isql не отображает план. Используйте SET PLAN ON для отображения плана в самом начале вывода запроса SELECT.

* Используйте SET PLANONLY для рассмотрения запроса и просмотра плана без фактического выполнения запроса. Это позволяет вам анализировать план любого запроса, а не только запросов SELECT.

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

! ! !

СОВЕТ. Не перекрывайте план оптимизатора, пока вы не протестировали ваш собственный и не убедились, что он выполняется быстрее на реальных данных.

. ! .

Более подробную информацию о планах запроса см. в разд. «Тема оптимизации» главы 20. Подробности использования isql см. в главе 37.

Как могут помочь индексы

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

Сортировка и группирование

Когда столбцы, указанные в предложениях ORDER BY или GROUP BY, являются индексированными, оптимизатор может упорядочить выходные данные, просматривая индексы, и собирать упорядочиваемые наборы быстрее, чем без использования индексов.

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

Соединения

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

Сравнения

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

Что индексировать

Величина времени, затрачиваемая на поиск во всей таблице, прямо пропорциональна количеству строк в таблице. Индекс для столбца может означать разницу между немедленным ответом на запрос и долгим ожиданием. Так почему бы не индексировать каждый столбец?

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

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

* условие поиска часто ссылается на столбец (Индекс поможет в поиске дат и чисел, когда ожидается прямое сравнение или вычисление BETWEEN. Поисковые индексы для строковых столбцов полезны, когда строки проверяются на точное соответствие или в предикатах STARTING WITH и CONTAINING. Они не годятся для предиката LIKE^[52].);

* столбец не включен в ограничение целостности, но на него часто ссылается условие в JOIN;

* предложение ORDER BY часто использует столбец для сортировки данных (Когда набор данных должен быть упорядочен по нескольким столбцам, составной индекс, соответствующий порядку, указанному в предложении ORDER BY, может увеличить скорость поиска^[53].);

* вам нужен индекс со специфическими характеристиками, не предоставляемыми данными или существующими индексами, такими как недвоичная сортировка, убывающая или возрастающая упорядоченность;

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

Вы не должны использовать индексы для столбцов, которые:

* редко используются в условиях поиска;

* являются часто изменяемыми неключевыми значениями, такими как значение времени или идентификация пользователя;

* имеют небольшое количество возможных или фактических значений в большом количестве строк;

* представляют собой двухзначное или трехзначное логическое значение.

Когда индексировать

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

Преимущества отложенного проектирования индексов:

* уменьшение «завуалированное(tm) производительности», на которую может накладываться тестирование функциональной полноты;

* более быстрая идентификация реальных источников узких мест;

* исключение ненужного или неэффективного индексирования.

Использование CREATE INDEX

Оператор CREATE INDEX создает индекс из одного или более столбцов таблицы. Индекс из одного столбца отыскивает только один столбец в ответ на запрос, в то время как индекс из нескольких столбцов отыскивает один

или более столбцов.

Синтаксис:

CREATE [UNIQUE] [ASC[ENDING] | DESC[ENDING]]

INDEX имя-индекса ON имя-таблицы (столбец [, столбец …]);

Обязательные элементы

Обязательные элементы в синтаксисе CREATE INDEX следующие:

* CREATE INDEX имя-индекса — именует индекс. Идентификатор должен отличаться от идентификаторов всех других объектов базы данных за исключением идентификаторов ограничений и столбцов. Хорошая идея использовать систему имен объектов схемы, это также поможет лучшей документированности;

! ! !

ПРИМЕЧАНИЕ. Начиная с версии 1.5 и выше работает автоматическое именование индекса по имени его ограничения.

. ! .

* имя-таблицы- имя той таблицы, для которой создается индекс;

столбец [, столбец …] — имя столбца или разделенный запятыми список имен столбцов, которые будут ключами индекса. Порядок столбцов значим для индексов. Более подробную информацию см. в разд. «Индексы из нескольких столбцов».

Пример

Следующее объявление создает неуникальный возрастающий индекс для столбца LAST_NAME (фамилия человека) в таблице PERSON. Он может быть полезным в условиях поиска типа WHERE LAST_NAME = ‘Johnston’ или WHERE LAST_NAME STARTING WITH ‘Johns’:

CREATE INDEX LAST_NAME_X ON PERSON(LAST_NAME);

Необязательные элементы

UNIQUE

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

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

Пример

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

CREATE UNIQUE INDEX STK_SIZE_COLOR_UQX

ON STOCK_ITEM (PRODUCT_ID, SIZE, COLOR);

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

Поиск дубликатов

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

SELECT PRODUCT_ID, UPPER(PRODUCT_NAME) FROM PRODUCT

GROUP BY PRODUCT_ID, UPPER(PRODUCT_NAME)

HAVING COUNT(*) > 1;

! ! !

ПРИМЕЧАНИЕ. Перевод значения столбца в верхний регистр, чтобы сделать поиск не чувствительным к регистру, не является необходимым с точки зрения уникальности данных. Тем не менее, если уникальность была «поломана» вводом ошибочных данных, мы можем отыскать все неправильные записи.

. ! .

Как вы поступите с дубликатами, зависит от того, что они означают в ваших бизнес- правилах, и от количества дубликатов, которые нужно уменьшить. Обычно, храни- мая процедура является наиболее эффективным способом это обработать. Хранимые процедуры подробно обсуждаются в главах 28-30.

ASC[ENDING] или DESC[ENDING]

Ключевые слова ASC[ENDING] и DESC[ENDING] определяют вертикальный порядок сортировки индекса, ASC задает сортировку индекса от меньшего к большему. Оно является значением по умолчанию и может быть опущено, DESC сортирует значения от большего к меньшему и должно быть указано, если требуется убывающий индекс. Убывающий индекс может быть полезным для запросов, которые отыскивают наибольшие значения (наибольший возраст, самый последний, самый большой и т.д.), а также при упорядоченном поиске или для выходных данных, которые должны быть отсортированы в убывающем порядке.

Пример

Следующее определение создает убывающий индекс для таблицы в базе данных employee:

CREATE DESCENDING INDEX DESC_X ON SALAR Y_HISTORY (CHANGE_DATE);

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

SELECT FIRST 10 EMP_NO, NEW_SALARY

FROM SALARY_HISTORY

ORDER BY CHANGE_DATE DESCENDING;

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

CREATE ASCENDING INDEX ASCEND_X ON SALARY_HISTORY (CHANGE_DATE) ;

Индексы для нескольких столбцов

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

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

столбцов в предложении ORDER BY начинается с первого столбца индекса, определенного для нескольких столбцов.

Firebird может использовать один элемент составного индекса для оптимизации поиска, если все предшествующие элементы индекса также используются. Рассмотрим сегментированный индекс для трех столбцов col_w, col_x и col_y в том порядке, как показано на рис. 18.1.

Рис. 18.1. Сегментированный индекс

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

SELECT <список столбцов> FROM ATABLE

ORDER BY COL_w, COL_X;

Он не будет использован для следующих запросов:

SELECT <список столбцов> FROM ATABLE

ORDER BY COL_x, COL_y;

/**/

SELECT < список столбцов> FROM ATABLE

ORDER BY COL_x, COL_w;

Предикаты OR в запросах

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

Предположим, требуется поиск:

. . .

WHERE А > 10000 OR В < 300 OR С BETWEEN 40 AND 80

. . .

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

Критерии поиска

Те же самые правила, которые применяются к предложению ORDER BY, также применимы к запросам, содержащим предложение WHERE. Следующий пример создает индекс по нескольким столбцам для таблицы PROJECT В базе данных employee.gdb:

CREATE UNIQUE INDEX PRODTYPEX ON PROJECT (PRODUCT, PROJ_NAME);

Оптимизатор для этого запроса выберет индекс PRODTYPEX, потому что предложение WHERE ссылается на первый сегмент этого индекса:

SELECT * FROM PROJECT

WHERE PRODUCT =’software’;

Напротив, он проигнорирует данный индекс для следующего запроса, потому что PROJ_NAME не является первым сегментом:

SELECT * FROM PROJECT

WHERE PROJ_NAME STARTING WITH ‘Firebird 1’;

Просмотр индексов

Для просмотра всех индексов, определенных в текущей базе данных, используйте в isql команду SHOW INDEX:

* чтобы просмотреть все индексы, определенные для конкретной таблицы, используйте команду:

SHOW INDEX имя-таблицы;

* для просмотра информации конкретного индекса используйте:

SHOW INDEX имя-индекса;

Изменение индекса

Активация/деактивация

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

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

Структуры двоичных деревьев, в которых хранятся индексы, могут стать разбалансированными. Переключение индекса из активного в неактивное состояние и обратно пересоздает и балансирует^[54] индекс.

Синтаксис:

ALTER INDEX имя-индекса INACTIVE | ACTIVE ;

Ошибка «индекс находится в использовании»

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

* в транзакции WAIT оператор ALTER INDEX ожидает, пока не завершится транзакция;

* с транзакции NOWAIT Firebird возвращает ошибку.

Информацию об установках блокировок транзакций см. в разд. «Разрешение блокировок» главы 26.

Изменение структуры индекса

В отличие от большинства операторов ALTER синтаксис ALTER INDEX не может быть использован для изменения структуры данного объекта. Для этого необходимо удалить индекс и заново его создать с использованием оператора CREATE INDEX.

Удаление индекса

Оператор DROP INDEX удаляет созданный пользователем индекс из базы данных.

Используйте DROP INDEX также в случае необходимости изменения структуры индекса: добавление, удаление сегментов, изменение порядка сегментов или изменение порядка сортировки. Вначале используйте оператор DROP INDEX для удаления индекса, затем — оператор CREATE INDEX для создания индекса с тем же именем и новыми характеристиками.

Синтаксис:

DROP INDEX ИМЯ;

Следующий оператор удаляет индекс из таблицы JOB:

DROP INDEX MINSALX;

Ограничения

Никакой пользователь не может удалить индекс, кроме его создателя, пользователя SYSDBA или (в POSIX) пользователя с привилегиями root.

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

Тема оптимизации: оптимальное индексирование

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

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

Этот раздел содержит некоторые указания по поддержанию ваших индексов в рабочем состоянии в полном объеме.

Действия по обслуживанию индексов

Индексы являются двоичными структурами, которые могут стать разбалансированными после многих изменений базы данных, особенно если вы пренебрегаете общим обслуживанием базы данных. Индексы могут быть сделаны сбалансированными^[55] множеством способов восстановления оптимального уровня производительности.

* Пересоздание индекса восстановит баланс его древовидной структуры за счет удаления устаревших записей, удаления и перемещения ветвей, созданных последовательными добавлениями данных. Инструментом для переключения индекса между активным и неактивным состояниями является оператор ALTER INDEX.

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

* Восстановление базы данных из резервной копии gbak также пересоздает индекс в первоначальном состоянии.

Улучшение селективности индекса

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

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

Измерение селективности

Селективность уникального индекса равна I. Все неуникальные индексы имеют значение меньше 1. Селективность (s) вычисляется как^[56]

s = n / количество строк в таблице

где n- количество различных экземпляров значения индекса в таблице. Чем меньше количество отличающихся экземпляров, тем меньше селективность. Индексы с более высокой селективностью выполняются лучше, чем индексы с низкой селективностью.

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

Пересчет селективности

Пересчет селективности индекса изменяет статистический множитель, хранящийся в системных таблицах. Оптимизатор читает его один раз при выборе плана- он не является особенно значимым для его выбора. Часто большие операции DML не обязательно повреждают распределение различных значений ключа индекса. Если индексирование разумно, то «демография» распределения значений может изменяться очень незначительно.

Знание наиболее правильной селективности индекса имеет большое значение для разработчика. Это дает основу для определения полезности индекса.

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

Работа с неконтролируемым индексом, который ухудшается по мере роста таблицы до того, как он начинает влиять на планы запросов, является важной частью настрой- ки базы данных. При этом большинство критических эффектов использования индекса с фактически низкой селективностью практически не влияют на оптимизатор и оказывают сильное воздействие на геометрию индекса^[57].

Почему низкая селективность наносит ущерб

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

Рис. 18.2 иллюстрирует этот двоичный механизм в простейшей форме

Когда появляются дублирующие значения, они помещаются в первый узел в начало «цепи» других дубликатов — это то, что происходит со значением ghi на нашей диаграмме. Такая структура называется цепочкой дубликатов.

Цепочки дубликатов^[58]

Цепочка дубликатов сама по себе является замечательной — все неуникальные индексы имеют ее. Изменение сегмента значения или удаление строки является дорого- стоящим, если цепочка дубликатов очень длинная. Одно из самого плохого, что вы можете сделать в базе данных Firebird — определить таблицу с миллионом строк, каждая из которых имеет одно и то же значение ключа для вторичного индекса, а затем удалить все эти строки. Последний сохраненный дубликат появляется в начале списка, а первый сохраненный дубликат — в конце. Обычно удаление начинается с первой сохраненной строки, затем удаляется вторая и т.д. Код обработки индекса будет проходить через всю цепь дубликатов для каждого удаления, всегда отыскивая нужную запись в самой последней позиции. Цитата Ann Harrison: «Это перемешивает кэш так, как вы никогда не видели».

Затраты на все такие «перемешивания» и «взбалтывания» никогда не связаны с транзакцией, которая удаляет или изменяет все строки в таблице. Изменение значения ключа или его удаление влияет на индекс позже, когда старые версии будут включены в процесс сборки мусора. Затраты проявятся для следующей транзакции, обращающейся к этим строкам и выполняющейся после завершения всех транзакций, которые были активны, когда выполнялось изменение или удаление^[59].

Инструментарий для индекса

Стандартная поставка Firebird содержит множество инструментов и приемов для получения состояния индексов и поддержания их в хорошей форме.

* Для получения значения селективности и других значимых характеристик индексов используйте анализатор статистики данных gstat. Позже в этой главе мы рассмотрим, как gstat может рассказать вам о ваших индексах.

* Инструментом для пересчета селективности индекса является оператор SET STATISTICS (обсуждаемый в следующем разделе), SET STATISTICS не пересоздает индекс.

* Лучшей из всех инструментов для чистки индексов является утилита резервного копирования и восстановления gbak. Восстановление базы данных из самой последней резервной копии пересоздает все индексы и заново вычисляет их селективность.

Использование SET STATISTICS

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

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

Оператор SET STATISTICS заново вычисляет селективность индекса. Этот оператор может быть выполнен в интерактивной сессии isql или запущен в приложении ESQL. Для выполнения оператора SET STATISTICS вы должны быть соединены с базой данных как пользователь, создавший индекс, как пользователь SYSDBA или (в POSIX) как пользователь с привилегиями операционной системы root.

Синтаксис:

SET STATISTICS INDEX ИМЯ;

Следующий оператор заново вычисляет селективность индекса в базе данных employee.gdb:

SET STATISTICS INDEX MINSALX;

Сам по себе оператор SET STATISTICS не решает текущие проблемы, являющиеся результатом предыдущего использования индекса, которые связаны с устаревшей статистикой селективности, потому что он не пересоздает индекс.

! ! !

СОВЕТ. Для пересоздания индекса используйте ALTER INDEX, или удалите и заново создайте его, или восстановите базу данных с резервной копии.

. ! .

Получение статистики по индексу

Firebird предоставляет утилиту командной строки, которая отображает статистические отчеты о состоянии объектов в базе данных. Этот инструмент создает множество отчетов о том, что происходит в базе данных. Основное внимание в этом разделе мы уделяем статистике по индексу. Остальные отчеты описываются после отчетов по индексу.

Инструмент командной строки gstat

Вам нужно запускать gstat на серверной машине, потому что это полностью локальная программа, которая не имеет доступа к базам данных как клиент. Ее размещение по умолчанию — каталог /bin в вашем каталоге инсталляции Firebird. Она выдает информацию об указанной базе данных и может быть использована SYSDBA или владельцем базы данных.

gstat в POSIX

Поскольку gstat обращается к файлам базы данных на уровне файловой системы, на платформах Linux и UNIX необходимо на уровне системы иметь доступ на чтение к этим файлам. Вы можете его получить одним из следующих способов.

* Соединитесь с той учетной записью, под которой выполняется сервер (по умолчанию пользователь firebird в версии 1.5, root или interbase в версии 1.0.x).

* Установите разрешение на чтение для вашей группы к файлу базы данных.

Интерфейс gstat

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

Синтаксис:

gstat [переключатели] имя-базы-данных

где имя-базы-данных- полный путь к базе данных.

Графические инструменты

gstat не является дружественным пользователю инструментом. Некоторые графические инструменты (например, IBAnalyst) четко выполняют ту же работу gstat по выводу результатов, используя Services API. Формы экранов были взяты из утилиты с открытыми кодами IBOConsole^[60].

Переключатели

В табл. 18.1 описаны переключатели gstat.

Таблица 18.1. Переключатели gstat

Переключатель	Описание
-user имя-пользователя	Проверяет имя пользователя перед доступом к базе данных
-pa[ssword] пароль	Проверяет пароль перед доступом к базе данных
-header	Выводит информацию заголовочной страницы, затем прекращает работу
-log	Выводит информацию заголовочной страницы и страницы протокола, затем прекращает работу
-index	Отыскивает и отображает статистику по индексам базы данных
-data	Отыскивает и отображает статистику по таблицам пользователя базы данных
-all	Это значение по умолчанию, если вы не запросили -index, -data или -all. Отыскивает и отображает статистику по -index и-data
-system	Как и -all, но дополнительно включает статистику по системным таблицам
-r	Отыскивает и отображает статистику по размеру и версиям записей (включая все версии)
-t список-таблиц	Используется вместе с -data. Ограничивает отображаемые данные таблицами из списка таблиц
-z	Печатает версию утилиты gstat

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

! ! !

ПРИМЕЧАНИЕ. Поскольку gstat выполняет собственный анализ на уровне файла, она не выполняется в контексте какой-либо транзакции. Следовательно, статистика по индексам также включает информацию по тем индексам, которые используются в незавершенных транзакциях. Например, не будет предупреждений, если отчет показывает некоторые дублирующие записи в индексе первичного ключа.

. ! .

Переключатель -index

Синтаксис:

gstat -i[ndex] база-данных

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

К сожалению, не существует способа получить статистику по одному индексу, однако вы можете ограничить результат одной таблицей, используя переключатель -t, за которым следует имя таблицы. Вы можете записать разделенный пробелами список имен таблиц для получения результатов более чем по одной таблице. Если имена ваших таблиц являются чувствительными к регистру — были объявлены идентификаторами, заключенными в кавычки, — то аргументы переключателя -t должны быть записаны в правильном регистре, но не должны заключаться в кавычки. Для таблиц с пробелами в их именах gstat вовсе не работает.

Вы можете добавить переключатель -system, чтобы включить сведения о системных индексах в отчет.

Чтобы запустить утилиту для базы данных employee и направить ее вывод в текстовый файл с именем gstat.index.txt, выполните следующее:

* в POSIX наберите (все в одной строке):

./gstat -index /opt/firebird/examples/employee.fdb -t CUSTOMER -user SYSDBA -password masterkey

> /opt/firebird/examples/gstat.index.txt

* в Win32 наберите (все в одной строке):

gstat -index

«c:Program FilesFirebirdFirebird_1_5examplesemployee.fdb» -t CUSTOMER

-user SYSDBA -password masterkey

> «c:Program FilesFirebirdFirebird_1_5examplesgstat.index.txt»

! ! !

ПРИМЕЧАНИЕ. Двойные кавычки для пути к базе данных требуются в Windows, если ваш путь содержит пробелы.

. ! .

На рис. 18.3 показано, как отображаются данные индексной страницы.

Рис. 18.3. Пример отображения данных индексной страницы

Что все это значит

Вначале появляется итоговая информация об индексе. В табл. 18.2 объясняются записи строка за строкой.

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

Таблица 18.2. Вывод gstat -i[ndex]

Элемент	Описание
Index	Имя индекса
Depth	Количество уровней в странице индексного дерева. Если глубина дерева индексной страницы превышает 3, то доступ к записям через индекс не будет максимально эффективным. Для уменьшения глубины дерева индексной страницы увеличьте размер страницы. Если увеличение размера страницы не уменьшает глубины, снова увеличьте размер страницы
Leaf buckets	Количество страниц самого низкого уровня (листовых) в дереве индекса. Это страницы, которые содержат указатели на записи. Страницы высокого уровня содержат косвенные связи
Nodes	Общее количество записей, индексированных в дереве. Должно быть равно количеству индексированных строк в дереве, хотя отчет gstat может включать узлы, которые были удалены, но не вычищены в процессе сборки мусора. Может также включать множество элементов для записей, у которых был изменен индексный ключ
Average data length	Средняя длина каждого ключа в байтах. Обычно имеет много меньшее значение, чем длина объявленного ключа, потому что выполняется сжатие суффикса и префикса
Total dup	Общее количество строк дубликатов индекса
Max dup	Количество дублирующих узлов в «цепочке», имеющих наибольшее количество дубликатов. Всегда будет нулем для уникальных индексов. Если число велико по сравнению с числом в Total dup, то это признак плохой селективности
Average fill	Это гистограмма с пятью 20-процентными полосами, каждая из которых показывает количество индексных страниц, чей средний процент заполнения находится в указанном диапазоне. Процент заполнения определяется соотношением пространства каждой страницы, содержащей данные. Сумма таких чисел дает общее количество страниц, содержащих индексные данные

Глубина индексов

Индекс является древовидной структурой со страницами на одном уровне, ссылающимися на страницы другого уровня и т.д. вплоть до страниц, указывающих на строки данных. Чем больше глубина, тем больше косвенных уровней. Строка Leaf bucket описывает страницы индекса самого низкого уровня, которые указывают на индивидуальные строки.

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

Рис. 18.4. Глубина индекса

Два фактора оказывают влияние на глубину: размеры страницы и ключа. Если глубина больше 3 и размер страницы меньше 8192, то увеличение размера страницы до 8192 или 16 386 должно уменьшить количество косвенных уровней и увеличить скорость.

! ! !

СОВЕТ. Вы можете вычислить приблизительный размер (в страницах) цепочки мах dup на основании статистических данных. Для получения количества узлов на странице разделите узлы (nodes) на количество листьев (leaf buckets). Умножение результата на максимальное количество дублирующих узлов (max dup) дает приблизительное количество страниц.

. ! .

Анализ некоторой статистики

Следующие выдержки являются выводом gstat -index для базы данных с плохой производительностью.

Анализ 1

Первый из поддерживаемых индексов, который был создан автоматически для внешнего ключа:

Index RDB$FOREIGNl4 (3)

Depth: 2, leaf buckets: 109, nodes: 73373

Average data length: 0.00, total dup: 73372, max dup: 32351

Fill distribution:

80 — 99% = 109

Строка Depth: 2, leaf buckets: 109, nodes: 73373 Сообщает нам, что нижний уровень индекса имеет 109 листьев (страниц), количество узлов 73 373. Это может и не быть общим количеством строк таблицы. С одной стороны, утилита gstat ничего не знает о транзакциях, поэтому она не может сообщить, найдены ли подтвержденные или неподтвержденные страницы. С другой — столбцы могут иметь значения NULL и не будут попадать в статистику.

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

В строке Average data length: 0.00, total dup: 73372, max dup: 32351 число max dup указывает длину самой длинной цепочки дубликатов, подсчитанной почти для половины узлов. Число total dup говорит, что каждый узел, за исключением одного, является дубликатом.

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

Примером этому было приложение формирования списка избирателей, которое сохраняло столбец страны проживания. Избирателей было приблизительно 3 миллиона, а регистрация была принудительной. База данных имела таблицу COUNTRY, содержащую более 300 стран, снабженную ключами в кодах стран CCCIT. Она присутствовала чуть ли не в каждой таблице базы данных в качестве внешнего ключа. Беда была в том, что почти все избиратели жили в одной стране.

Средняя длина данных (Average data length) — это средняя длина хранимого ключа. Здесь мало что можно сделать с объявленной длиной. Нулевое значение средней длины означает лишь то, что в процессе сжатия не осталось «пищи» для вычисления среднего значения.

Строка Fill distribution показывает, что все 109 страниц находятся в диапазоне 80-99 процентов, что является хорошим заполнением. Распределение заполнения является долей пространства каждой страницы, используемой для данных и указателей. От восьмидесяти до девяноста процентов — это хорошо. Меньшее распределение заполнения является весьма серьезным напоминанием, что вы должны пересоздать индекс.

Анализ 2

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

Index RDB$PRIMARY10 (0)

Depth: 3, leaf buckets: 298, nodes: 73373

Average data length: 10.00, total dup: 0, max dup: 0

Fill distribution:

0 — 19% = 1

80 — 99% = 297

Длина ключа 10 означает, что выполнено некоторое сжатие. Это нормально и хорошо. То что одна строка мало заполнена- вполне нормально: количество узлов не соответствует точно страницам.

Анализ 3

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

Index RDB$FOREIGN263 (1)

Depth: 1, leaf buckets: 10, nodes: 481

Average data length: 0.00, total dup: 480, max dup: 480

Fill distribution:

0 — 19% = 10

Total dup и max dup идентичны — каждая строка имеет одинаковое значение в ключе индекса. Селективность не может быть хуже этой. Уровень заполнения, очень низкий для всех страниц, наводит на мысль о разнородных удалениях. Если бы это не было маленькой таблицей, такой индекс был бы ужасен.

Данная таблица — очередь обработки — очень динамична, она хранит до 1000 новых строк в день. После проверки данных строки переносятся в порождающие таблицы, а строки разрабатываемой таблицы удаляются, приводя к замедлению работы системы. Частое резервное копирование и восстановление базы данных необходимо, чтобы дела шли нормально.

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

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

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

* Если удаления должны быть последовательными, выберите время, чтобы получить исключительный доступ и использовать ALTER INDEX для пересоздания индекса. Это будет более быстро и предсказуемо, чем инкрементная сборка мусора в огромной цепочке дубликатов.

Другие переключатели gstat

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

Переключатель -header

Эта строка

gstat -header база-данных

отображает суммарную информацию заголовочной страницы базы данных. На рис. 18.5 показан пример.

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

Рис. 18.5. Пример вывода заголовочной страницы утилитой gstat

Таблица 18.3. Вывод gstat -h[eader]

Элемент	Описание
Flags	Флаги
Checksum	Контрольная сумма заголовочной страницы. В прототипе (InterBase) это было уникальное значение, вычислявшееся по всем данным заголовочной страницы. В Firebird это всегда 12 345. Когда заголовочная страница сохраняется на диске, а затем считывается, контрольная сумма найденной страницы сравнивается с 12 345, и если они не соответствуют, то вызывается ошибка контрольной суммы. Это перехватывает некоторые виды физического разрушения
Generation	Каждый раз увеличивается на единицу, когда заголовочная страница записывается на диск
Page size	Текущий размер страницы базы данных в байтах
ODS version	Версия структуры на диске (ODS) для базы данных. Это будет 10 для версии 1,0.x и 10.1 для версии 1.5
Oldest transaction	Идентификатор самой старой «заинтересованной» транзакции. Информацию об этом см. в главе 25
Oldest active	Идентификатор самой старой активной транзакции
Oldest snapshot	Идентификатор самой старой транзакции, которая не является в настоящий момент подходящей для сборки мусора (т. е. эта и другие, более поздние транзакции не являются для этого подходящими)
Next transaction	Идентификатор, который Firebird назначит следующей транзакции. Разница между самой старой активной транзакцией и следующей транзакцией определяет, когда начнется чистка базы данных^[61]. Значение по умолчанию 20 000. См. разд. «Гигиена базы данных» главы 15
Bumped transaction	Теперь устарело
Sequence number	Последовательный номер заголовочной страницы. Всегда ноль
Next connection ID	Номер идентификатора следующего соединения с базой данных
Implementation ID	Архитектура аппаратуры, на которой была создана база данных
Shadow count	Количество наборов оперативных копий для базы данных
Number of cache buffers	Размер в страницах кэша базы данных. Ноль означает, что база данных использует значение по умолчанию сервера (DefaultDbCachePages в firebird.config, default_cache_pages в ibconfig/isc_config для версии 1.0.x)
Next header page	Номер страницы следующей заголовочной страницы — хотя, похоже, это не поддерживается
Database dialect	Диалект SQL базы данных
Creation date	Дата создания базы данных или последнего восстановления из резервной копии
Attributes	force write означает режим принудительной записи. no reserve указывает, что на страницах не резервируется место для старых версий данных. Это позволяет более плотно упаковывать данные на каждой странице, в силу чего база данных занимает меньше дискового пространства. Это идеал для баз данных только для чтения. shutdown означает, что работа с базой данных запрещена для всех пользователей, кроме SYSDBA
Variable header data	Интервал очистки (sweep interval). Информация о вторичных файлах (если присутствуют)

Переключатель -data

Следующая строка

gstat -data база-данных

просматривает в базе данных таблицу за таблицей, отображая итоговую информацию о страницах данных. Для включения в отчет системных таблиц (RDB$XXX) добавьте переключатель -system. На рис. 18.6 показан пример вывода.

Рис. 18.6. Пример итогового вывода по страницам данных в gstat

Вывод в командной строке аналогичен.

COUNTRY (31)

Primary pointer page: 190, Index root page: 19

Data pages: 1, data page slots: 1, average fill: 26%

Fill distribution:

0 — 19% = 0

20 — 39% = 1

40 — 59% = 0

60 — 79% = 0

80 — 99% = 0

Для каждой таблицы базы данных отображаются числа, показанные в табл. 18.4.

Глава 18. Индексы

375

Таблица 18.4. Вывод gstat -d[ata]

Элемент	Описание
Primary pointer page	Номер первой страницы косвенных указателей на страницы, хранящие данные таблицы
Index root page	Номер страницы, которая является первой страницей указателей на индексы таблицы
Data pages	Общее количество страниц, в которых хранятся данные таблицы. Этот счетчик включает страницы, хранящие неподтвержденные версии записей и мусор, потому что gstat не может их отличить друг от друга
Data page slots	Количество указателей на страницы базы данных, содержащихся на страницах указателей. Должно равняться числу страниц данных
Average fill	Это гистограмма из пяти 20-процентных «полос», каждая из которых показывает количество страниц данных, чье среднее заполнение попадает в этот диапазон. Процент заполнения определяется соотношением пространства каждой страницы, содержащей данные. В нашем примере среднее заполнение низкое, потому что база данных employee.gdb содержит небольшие структуры записей, и их не так много. Сумма этих чисел дает общее количество страниц, содержащих данные
Fill distribution	Обобщающая гистограмма распределения использования памяти для всех страниц, выделенных в таблице. В нашем примере пока используется только одна страница, и она имеет менее 40% заполнения

Ограничение вывода для gstat -data

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

Синтаксис:

gstat -data база-данных -t имя-таблицы1 [имя-таблицы2 [ имя-таблицы3 ..]]

! ! !

ПРИМЕЧАНИЕ. Имена таблиц должны быть набраны в верхнем регистре. К сожалению, gstat не поддерживает переключатель -t[able-list] для баз данных, которые используют чувствительные к регистру идентификаторы таблиц, заключенные в кавычки.

. ! .

Переключатель -r[ecords]

Следующая строка

gstat -r база-данных

отображает статистику по размерам и версиям записей.

* Для строк: среднее значение длины строк в байтах и общее количество строк в таблице.

* Для старых версий: среднее значение длины версий в байтах, общее количество версий в таблице и максимальная цепочка версий для записи.

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

Пример

Три таблицы (CAULDRON, CAULDRON1 и CAULDRON2) имеют одинаковые метаданные и объем 100 000 записей. Номинальная, несжатая длина записи 900 байт.

CAULDRON — чистая таблица без старых версий строк. Средняя длина хранимой строки 121 байт — приблизительно 87% сжатия.

CAULDRON1 имеет активную, все еще выполняющуюся транзакцию:

DELETE FROM CAULDRON1;

Каждая строка имеет нулевую (0.00) длину, потому что первичная запись является заглушкой удаления (delete stub), которая содержит только заголовок строки. Все подтвержденные записи были восстановлены как старые версии и сжаты до того же размера, который они имели, когда были первичными записями. Таблица содержит то же количество страниц (4000), что и до операции DELETE. Средний коэффициент заполнения составляет от 85 до 95% для размещения всех заглушек удаления.

CAULDRON2 имеет активную, все еще выполняющуюся транзакцию:

UPDATE CAULDRON2 SET F20FFSET = 5.0

Измененные записи увеличили размер на 2 байта (с 121 до 123), что можно отнести к более низкому уровню сжатия.

Значение 5.0 заменило большинство отсутствующих или нулевых значений, что сделало значение этого поля отличным от других полей. Теперь существует 100 000 старых версий со средним значением 10 байт каждая. Средний коэффициент заполнения увеличен до 99%, а таблица выросла с 138 до 4138 страниц.

> gstat proj.gdb -r -t CAULDRON CAULDRONI CAULDRON2

. . .

Analyzing database pages . . .

CAULDRON (147)

Primary pointer page: 259, Index root page: 260

Average record length: 120.97, total records: 100000

Average version length: 0.00, total versions: 0, max versions: 0

Data pages: 4000, data page slots: 4000, average fill: 85%

Fill distribution:

0 -19%=0

-39%=0

40 -59%=0

60 -79%=0

80 -99%=4000

CAULDR0N1 (148)

Primary pointer page: 265, Index root page: 266

Average record length: 0.00, total records: 100000

Average version length: 120.97, total versions: 100000, max versions: 1

Data pages: 4000, data page slots: 4000, average fill: 95%

Fill distribution:

0 -19%=0

20 -39%=0

40 -59%=0

60 -79%=0

80 -99%=4000

CAOLDRON2 (149)

Primary pointer page: 271, Index root page: 272

Average record length: 122.97, total records: 100000

Average version length: 10.00, total versions: 100000, max versions: 1

Data pages: 4138, data page slots: 4138, average fill: 99%

Fill distribution:

0 -19%=0

20 -39%=0

40 -59%=0

60 -79%=0

80 -99%=4138

! ! !

СОВЕТ. Для API-программистов функция API Firebird isc_database_info() и Services API предоставляют элементы, которые делают возможным синхронизировать выполнение поиска и получение статистики по базе данных в ваших программах приложений. Для программистов Delphi, C++ Builder и Kylix доступны различные наборы компонентов для получения статистики базы данных.

. ! .

Пора дальше

Здесь мы завершаем обсуждение объектов базы данных и перемещаем фокус на язык создания и изменения данных. Наше исследование начинается с общего взгляда на SQL в терминах стандартов и как реализация Firebird разбивается на множество перекрывающихся подмножеств. После этого в главе 20 мы начинаем более подробное рассмотрение данных как множеств и операторов языка манипулирования данными (Data Manipulation Language, DML) для определения данных и манипуляций с ними.

ЧАСТЬ V. Firebird SQL.

ГЛАВА 19. Язык SQL в Firebird.

SQL (произносится «эс кю эль»^[62]) — это подъязык данных для доступа к реляционным системам управления базами данных. Его элементы, синтаксис и поведение стандартизовали ANSI и ISO в 1986 году.

С этого времени SQL пересматривался три раза: SQL-89 (опубликован в 1989 г.), SQL-92 (1992 г. или около этого) и самый последний SQL 3, рабочая версия, опубликованная как часть SQL-99.

Язык запросов стандарта SQL является непроцедурным языком, т. е. он ориентирован на результаты операций, а не на способы получения результатов. Его назначение — быть основой для подъязыка, используемого в рамках включающего языка программирования. Цель стандартов — описать механизм внешнего уровня, посредством которого заданный запрос вернет предсказуемый результат, независимо от того, как сервер базы данных внутренне манипулирует данными.

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

Firebird и стандарты

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

Язык SQL Firebird близко соответствует стандартам SQL-92 (ISO/IEC 9075:1992) на начальном уровне (entry level). Firebird вводит множество возможностей в соответствии с более поздним релизом стандарта SQL-99. Хотя SQL в Firebird близко соответствует стандартам, существуют небольшие отличия.

Операторы SQL

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

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

* Операторы CREATE, ALTER и DROP над объектами метаданных (также называемые объектами схемы или элементами схемы). Язык таких запросов называется языком определения данных (Data Definition Language, DDL).

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

• поиска и преобразования (SELECT) образов таких наборов данных из хранилища данных для чтения приложениями;

• изменения состояния базы данных путем добавления, изменения и удаления указанных наборов (операторы INSERT, UPDATE и DELETE).

Такие операторы, которые выполняют действия над данными, относятся к языку, называемому языком манипулирования данными (Data Manipulation Language, DML).

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

* Встраиваемый SQL (Embedded SQL, ESQL) — это «базовая» реализация SQL, состоящая из синтаксиса DDL и DML, которые включаются и в другие подмножества, где это возможно. Это было первоначальной реализацией SQL в предшественнике InterBase, разработанной для включения в клиентские приложения и требующей препроцессора GPRE.

* Динамический SQL (Dynamic SQL, DSQL) — это подмножество наиболее часто используется сегодня. Оно используется во всех программах интерфейса с базой

— данных, которые общаются с сервером через интерфейс прикладного программирования (Application Programming Interface, API). Некоторые команды DDL, доступные в ESQL, которые не могут быть реализованы в DSQL, заменяются вызовами функций API.

* Интерактивный SQL (Interactive SQL, ISQL)- это язык, реализованный в утилите командной строки isql. Он основан на DSQL с расширениями просмотра метаданных и некоторой системной статистики, а также для управления сессиями isql.

* Процедурный SQL (Procedural SQL, PSQL) — это язык для написания хранимых процедур и триггеров. Он состоит из всех операторов DML с добавлением множества процедурных расширений.

Язык определения данных (DDL)

При определении метаданных для использования в базе данных Firebird мы используем лексикон операторов и параметров стандартов SQL для создания объекта с его типом и именем — или идентификатором, — а также для задания и изменения его атрибутов. В этом лексиконе также присутствуют операторы для удаления объектов.

Запросы с использованием DDL зарезервированы для целей определения метаданных, следовательно:

* аккуратно управляйте ими, если вы реализуете их использование в приложениях конечного пользователя;

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

Язык DDL в Firebird описан в частях III и IV. Определение просмотров, предоставление и отмена привилегий SQL также относятся к DDL. Просмотры, которые объединяют операторы DDL и DML, обсуждаются в главе 24. Определение и поддержка разрешений SQL описывается в главе 35.

Язык манипулирования данными (DML)

Операторы DML, их синтаксис и выражения для поиска и манипулирования наборами данных являются предметом рассмотрения этой части книги.

* В главе 20 вводится концепция наборов, структура и синтаксис запросов DML. Глава включает разд. «Тема оптимизации», где рассматривается работа с оптимизатором запросов.

* Глава 21 описывает функции, операции и выражения, порядок их использования.

* В главе 22 рассматриваются запросы, которые оперируют с множеством таблиц при использовании соединений (joins), подзапросов (sub-queries) и объединений (unions).

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

* Глава 24 содержит описание и использование просмотров, а также других наследуемых объектов типа таблиц.

Возможности встраиваемого языка (ESQL)

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

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

ESQL недопустим в хранимых процедурах и триггерах, а процедурный язык (PSQL) недопустим во встроенном SQL. ESQL может выполнять хранимые процедуры. ESQL используется в программах, написанных на традиционных языках программирования, таких как С или COBOL. Каждому оператору ESQL должен предшествовать SQL-оператор EXEC. Препроцессор GPRE преобразует операторы ESQL в структуры данных используемого языка программирования и вызовы сервера Firebird.

Более подробную информацию см. в «Embedded SQL» (Встраиваемый SQL) в документации Borland по InterBase 6.x или EmbedSQL.pdf в соответствующем комплекте электронной документации^[63].

Динамический в сравнении со статическим SQL

Операторы SQL, включенные в код и обработанные препроцессором, иногда называются статическим SQL. В отличие от них операторы, которые генерируются клиентским приложением и передаются для выполнения на сервер во время работы, называются динамическим SQL (DSQL).

Если вы не пишете код для приложений ESQL, вы используете DSQL. Операторы, выполняемые в утилите интерактивного SQL (isql) или в другой интерактивной утилите, являются операторами DSQL, таким же образом они обрабатываются в клиентских приложениях, которые используют напрямую или опосредованно API (через драйверы доступа к базе данных, такие как ODBC, JDBC или BDE).

В приложениях с Embedded SQL статический SQL позволяет передавать запросы в API Firebird, вместо того, чтобы использовать препроцессор и макросы для формирования структур API. Поскольку весь запрос полностью подготовлен, он может выполняться быстрее динамических операторов, которые передаются серверу, где выполняется их синтаксический анализ и подготовка во время выполнения программы.

Разновидности подмножеств языка

Преднамеренно или случайно существуют некоторые незначительные отличия между подмножествами языка SQL в Firebird.

* Формат некоторых обычных операторов SQL может слегка изменяться в статическом и динамическом вариантах SQL.

* Терминаторы операторов могут изменяться в разных подмножествах языка:

• операторы PSQL и ESQL завершаются точкой с запятой;

• в операторах DSQL, передаваемых через структуры API, терминаторы отсутствуют;

• операторы DSQL, вводимые в интерактивной утилите запросов isql требуют терминаторов, которые могут быть установлены при использовании SET TERM в любой печатаемый символ из первых 127 символьного подмножества ASCII.

Интерактивный SQL (ISQL)

Инструмент интерактивных запросов isql использует операторы DSQL вместе с двумя подмножествами расширенных команд (группы SET xxx и SHOW xxx), которые позволяют интерактивно выполнить некоторые установки и запросы к схеме соответственно. Некоторые команды SET могут быть также включены в скрипты определения данных (скрипты DDL для пакетного выполнения в isql) и в Embedded SQL.

Подробную информацию о подмножестве языка isql см. в главе 37.

Процедурный язык (PSQL)

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

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

Firebird предоставляет такие конструкции в виде процедурного языка (иногда называемого PSQL), который является набором расширений SQL, используемых программистами вместе с вариантом языка ESQL для написания исходных кодов для хранимых процедур и триггеров. Расширения PSQL включают управление потоком выполнения, условные выражения и средства обработки ошибок. Язык включает уникальную возможность генерации многострочных выходных наборов, к которым может быть осуществлен прямой доступ с использованием операторов SELECT.

Из языка исключены некоторые конструкции SQL, в частности все операторы DDL. При этом в Firebird 1.5 и выше в PSQL поддерживается синтаксис EXECUTE STATEMENT для выполнения команд DSQL, включающих некоторые операторы DDL.

PSQL для хранимых процедур и триггеров подробно описывается в части VII.

Диалекты SQL

В Firebird каждый клиент и база данных имеют диалект SQL, атрибут, указывающий серверу, как интерпретировать возможности и элементы, которые реализованы по- разному в базах данных Borland InterBase до версии 6.

Диалект позволяет серверу Firebird распознавать, принимать и корректно обрабатывать более ранние возможности и элементы баз данных (диалект 1), получать доступ к этим старым данным для их преобразования в новые возможности и элементы (диалект 2) или использовать полный набор возможностей, элементов и правил Firebird для конвертированных или вновь создаваемых баз данных (диалект 3).

Возможно создание новой базы данных в Firebird диалекта 1 или диалекта 3. Не рекомендуется создавать новые базы в диалекте 1, поскольку, в конечном счете, прекратится его поддержка. Невозможно создание базы данных диалекта 2, потому что диалект 2 предназначен для конвертирования баз данных диалекта 1 в диалект 3. Диалект 2 может быть применен только к клиентскому соединению.

Ресурсы SQL

Приложение 1 содержит алфавитный список описаний внешних функций.

Используйте алфавитный указатель в конце этой книги для поиска неизвестных терминов.

Книги

Если предыдущие ваши «контакты» с SQL были минимальными, хорошая книга по SQL-92 будет бесценной. Следующий список (который не является исчерпывающим) может быть вам полезен.

Joe Celko пишет по SQL книги, предназначенные для решения проблем. Вот некоторые из них: «Joe Celko’s SQL For Smarties: Advanced SQL Programming», «Joe Celko’s Data and Databases: Concepts in Practice», и «Joe Celko’s SQL Puzzles and Answers». Здесь описывается главным образом стандартный SQL, может быть с некоторым уклоном в Oracle.

David Rozenshtein и Tom Bondur «The Essence of SQL» — очень лаконичная книга в большей мере для начинающих.

Judith S. Bowman, Sandra Emerson, Marcy Darnovsky «The Practical SQL Handbook» — настольный справочник по стандарту SQL, получивший хорошие отзывы.

Hugh Darwen и Chris Date «A Guide to the SQL Standard» содержит все, что вам нужно знать об SQL-92, а также многое из того, о чем вы не знаете, что вы этого не знаете.

Jim Melton и Alan Simon «Understanding the New SQL: A Complete Guide» описывает SQL-89 и SQL-92. Это всеобъемлющий красиво оформленный справочник для начинающих. Включает некоторые базовые теории моделирования.

Martin Gruber «Mastering SQL» является переработанной и расширенной версией книги того же автора «Understanding SQL», которая делает стандартный SQL доступным даже для начинающих. Позволяет быстро приобрести солидные умения в разработке.^[64]

Свободная поддержка SQL

По всем вопросам, связанным с SQL Firebird, присоединяйтесь к форуму поддержки Firebird на http://www.yahoogroups.com/community/firebird-support. Это добровольный список адресов электронной почты, где знающие и новые пользователи Firebird делятся своим опытом. Если вы предпочитаете интерфейс конференции, то здесь зеркально отображаются новости: news://news.atkin.com/egroups.ib-support. Вы можете послать список сообщений через зеркальную конференцию, если подпишетесь на список рассылки и будете использовать тот же адрес отправителя.

Пора дальше

Язык манипулирования данными (DML) является подмножеством языка SQL, которое мы используем, чтобы определить наборы данных для чтения или обработки в приложениях. В следующей главе мы рассмотрим базовый синтаксис «большой четверки» операторов SQL: SELECT, INSERT, UPDATE и DELETE.

ГЛАВА 20. Запросы DML.

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

Строго говоря, оператор не является запросом, пока он не будет передан серверу. При этом большинство разработчиков используют термины оператор и запрос одинаково.

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

Наборы данных

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

Люди часто небрежно называют наборы «запросами». Эти слова не являются синонимами.

Таблица является набором

Таблица является набором, чья полная спецификация может быть получена из системных таблиц сервером базы данных, когда к таблице происходит обращение из запроса, полученного от клиента. Сервер Firebird выполняет свои собственные внутренние запросы к системным таблицам для получения метаданных, необходимых для выполнения клиентских запросов.

Выходные наборы

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

! ! !

ПРИМЕЧАНИЕ. Выражение «неупорядоченные строки» означает следующее. Строки таблицы хранятся без каких-либо атрибутов, и порядок неупорядоченных наборов может непредсказуемо меняться от одного запроса к другому.

. ! .

Например, следующий запрос создаст выходной набор из трех столбцов из таблицы TABLEA, содержащий каждую строку, которая соответствует условиям, указанным в предложении WHERE. Строки будут отсортированными, следовательно, строка с наименьшим значением в COL1 появится первой:

SELECT COL1, COL2, COL3 FROM TABLEA

WHERE COL3 = ‘Mozart’

ORDER BY COL1;

Если не будет задано предложение WHERE, ТО набор будет содержать все строки из таблицы TABLEA, а не только те, в которых столбец COL3 будет иметь значение ‘Mozart’.

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

SELECT * FROM TABLEA;

определяет выходной набор, состоящий из всех столбцов и всех строк таблицы TABLEA.

Кардинальное число и положение

Одним из терминов, который иногда можно встретить в отношении наборов, включая таблицы- является кардинальное число (cardinality, «мощность множества»). Оно описывает количество строк в наборе, который может быть таблицей или выходным набором. Реже можно встретить кардинальное число строки или кардинальное число значения ключа, что означает позицию строки в упорядоченном выходном наборе.

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

Входные наборы

Как часть SELECT … FROM В запросе на поиск задает набор для вывода или для операции курсора, точно так же и другие операторы DML (INSERT, UPDATE и DELETE) задают входные наборы, идентифицируя данные, над которыми выполняется операция.

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

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

INSERT INTO TABLEB(COLA, COLB, COLC)

VALUES(99, ‘Christmas 2004’, ‘2004-12-25’);

Оператор INSERT имеет альтернативный синтаксис, в котором предложение VALUES о заменяется на выборку набора из одной или более других таблиц, реальных или виртуальных. Операторы INSERT подробно обсуждаются в разд. «Оператор INSERT».

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

UPDATE TABLEB

SET COLB =’Labor Thanksgiving Day (Japan)’,

COLC = ‘2002-23-11’

WHERE . . .

Операторы UPDATE подробно обсуждаются в разд. «Оператор UPDATE».

Запрос DELETE не может задавать столбцы в своем входном наборе — этот набор всегда определяется неявно * (все столбцы). Он идентифицирует строки, принимающие участие в операции, в предложении WHERE. Например, следующий запрос удалит все строки, где COLC (типа данных DATE) является датой, раньше 13 декабря 1999 г.:

DELETE FROM TABLEB

WHERE COLC < ‘1999-12-13’;

Операторы DELETE подробно обсуждаются в разд. «Оператор DELETE».

Выходные наборы в качестве входных наборов

Сгруппированные или агрегатные запросы

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

Об агрегатных запросах см. главу 23.

Потоки и реки для соединений

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

Группа подпрограмм ядра Firebird, называемая оптимизатором, проверяет спецификацию запроса соединения и доступные индексы на предмет стоимости обработки запроса. Этот процесс называется оптимизацией. Оптимизатор генерирует план, являющийся «лучшей по стоимости» картой, которую выбирает сервер для генерации финальной «выходной реки» в последующих выполнениях этого оператора.

Синтаксис соединения (JOIN) обсуждается в главе 22. См. разд. «Тема оптимизации» главы 22, где обсуждается оптимизатор и планы запроса.

Наборы курсора

Оператор SELECT может объявлять набор, который вовсе не является выходным для клиента, но остается на сервере, чтобы работать как курсор на стороне сервера. Сам курсор является указателем; приложение дает ему указание по запросу читать по порядку строки одну за другой на основании подготовленного (prepared) оператора SELECT.

Объявление именованного курсора, который должен быть вначале скомпилирован в ESQL или задан в структуре API в DSQL, включает переменную оператора клиентской стороны, которая указывает на этот оператор. Клиентское приложение является ответственным за то, что подготовленный оператор доступен для назначения соответствующему указателю при выполнении программы.

PSQL имеет языковое расширение, которое принимает следующую форму:

FOR SELECT <любая допустимая спецификация выборки>

INTO <список предварительно объявленных локальных переменных> DO

BEGIN

Необязательные действия над переменными>;

SUSPEND;

END

Это синтаксис неименованного курсора^[65].

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

Другой оператор может быть связан с открытым курсором при использовании WHERE CURRENT OF <имя-курсора> вместо условия поиска для выполнения позиционированного изменения или удаления строк, «отмеченных» набором курсора.

Реализация курсоров

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

* Встраиваемый SQL (ESQL) предоставляет оператор DECLARE CURSOR^[66] для реализации предварительно компилированного объявления именованного курсора.

* Для использования курсора динамическое приложение должно предварительно объявить его в функции isc_dsqi_set_cursor_name^[67]. Только некоторые компоненты реализуют такой интерфейс, большинство других — нет.

* Язык PSQL предоставляет синтаксис для работы с именованными и неименованными курсорами локально внутри хранимой процедуры или триггера. Подробную информацию см. в главе 29.

! ! !

ПРИМЕЧАНИЕ. За исключением техник работы с курсорами в PSQL сами курсоры выходят за пределы темы настоящей книги. Подробную информацию см. в главе 30.

. ! .

Вложенные наборы

Вложенные наборы формируются с использованием синтаксиса специального вида выражений SQL, называемых подзапросами. Этот вид выражений принимает форму вложенного оператора SELECT, который может быть включен в список спецификаций столбцов главного запроса для получения одного значения строки, или в предложение WHERE как часть условия поиска. Допустимый синтаксис SELECT изменяется в зависимости от контекста, в котором используется подзапрос.

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

SELECT COL1, COL2, COL3,

(SELECT COLA FROM TABLEB WHERE COLX=’Espagnol’)

AS DESCRIPTION

FROM TABLEA

WHERE … ;

Обратите внимание на использование ключевого слова AS для присваивания имени (DESCRIPTION) наследуемому столбцу. Это делать необязательно, но рекомендуется для ясности кода.

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

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

Привилегии

Чтение из таблиц и запись в таблицы являются привилегиями базы данных, управляемыми объявлениями, выполненными с помощью операторов GRANT и REVOKE (см. главу 35).

Оператор SELECT

Оператор SELECT является для клиентов фундаментальным методом поиска наборов данных в базе данных. Он имеет следующую основную форму:

SELECT

[FIRST (m)] [SKIP (n)] [[ALL] | DISTINCT]

<список-столбцов> [, [имя-столбца] | выражение | константа ]

AS имя-алиаса]

FROM <таблица-или-процедура-или-просмотр>

[{[[INNER] | [{LEFT | RIGHT | FULL} [OUTER]] JOIN}]

<таблица-или-процедура-или-просмотр>

ON <условия-соединения> [{JOIN…}]

[WHERE <условия-поиска>]

[GROUP BY <список-группируемых-столбцов>]

[HAVING <предикат-группирования>]

[UNION <выражение-выбора> [ALL]]

[PLAN <выражение-плана>]

[ORDER BY <список-столбцов>]

[FOR UPDATE [OF столбец1 [, столбец2…]] [WITH LOCK]]

Предложения в операторе SELECT

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

Необязательные режимы выборки

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

ALL

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

DISTINCT

Этот режим выборки подавляет вывод всех дубликатов строк в выходной набор. Например, таблица EMPLOYEE_PROJECT хранит пересекающиеся записи для каждой комбинации служащего (EMP_NO) и проекта (PROJ_ID), поддерживая отношение многие-ко- многим. Конкатенация EMP NO + PROJ_ID образует первичный ключ. Оператор

SELECT DISTINCT EMP_NO, PROJ_ID FROM EMPLOYEE_PROJECT;

вернет 28 строк — т. е. все строки, это является тем же самым, что и SELECT [ALL], потому что каждое появление (EMP_NO + PROJ_ID) является по своей природе уникальным, отличным от других.

Операторы

SELECT DISTINCT EMP_NO FROM EMPLOYEE_PROJECT;

SELECT DISTINCT PROJ_ID FROM EMPLOYEE_PROJECT;

вернут, соответственно, 22 и 5 строк.

Вычисление отличий применяется ко всем выходным столбцам, что делает оператор DISTINCT полезным в некоторых запросах, которые используют соединения для получения ненормализованного набора. Тщательно тестируйте этот режим для проверки, что он создает тот результат, который вы ожидаете^[68].

FIRST(m) SKIP(n)

Необязательные ключевые слова FIRST(m) и/или SKIP(n), если присутствуют, предшествуют всем другим спецификациям. Они задают режим выбора первых m строк в упорядоченном наборе и игнорирования первых n строк в упорядоченном наборе, соответственно. Не имеет смысла использовать эту конструкцию в неупорядоченном наборе^[69]. Очевидно, нужно предложение ORDER BY для использования условия упорядочения, которое сделает осмысленным выбор кандидатов строк.

Эти два ключевых слова могут быть использованы вместе или индивидуально. Аргументы m и n должны быть целыми или выражениями, дающими целые числа. Круглые скобки вокруг значений тип требуются для выражений и не обязательны для простых целых аргументов.

Поскольку FIRST и SKIP выполняются над набором, полученным на основании остальной части спецификации, не следует ожидать, что они сделают выполнение запроса более быстрым. Преимущества в производительности получаются от сокращения сетевого трафика^[70].

Следующий пример вернет пять строк, начиная со строки 101 упорядоченного набора:

SELECT FIRST 5 SKIP 100 MEMBER_ID, MEMBERSHIP_TYPE, JOIN_DATE

FROM MEMBERS

ORDER BY JOIN DATE;

! ! !

СОВЕТ. Для получения n строк с самыми большими значениями столбцов в соответствии с условиями упорядочения установите порядок сортировки DESC[ENDING].

. ! .

SELECT <список-столбцов>

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

* идентификатор столбца, который хранится в таблице, задан в просмотре или объявлен как выходной аргумент хранимой процедуры. При некоторых условиях идентификатор столбца должен содержать уточнение в виде имени или алиаса содержащей его таблицы;

* простое или сложное выражение, сопровождаемое идентификатором времени выполнения;

* константное значение, сопровождаемое идентификатором времени выполнения;

* контекстная переменная сервера, сопровождаемая идентификатором времени выполнения;

* символ *, часто называемый «звездочкой выбора», который задает все столбцы. Хотя SELECT * не исключает выбор одного или более столбцов из той же таблицы индивидуально, вообще-то в этом нет смысла. Чтобы включить дубликаты столбцов для специальных целей, применяйте для него ключевое слово AS и алиас, возвращая его как вычисляемое (только для чтения) поле.

Все следующие спецификации SELECT правильны.

Простой список столбцов:

SELECT COLUMN1, COLUMN2 …

Уточненные имена столбцов, требуемые для спецификаций со многими таблицами:

SELECT

TABLEA.ID,

TABLEA.BOOK_TITLE,

TABLEB.CHAPTER_TITLE,

CURRENT_TIMESTAMP AS RETRIEVE_DATE . . .

Выражение (агрегирующее):

SELECT MAX (COST * QUANTITY) AS BEST_SALE …

Выражение (преобразующее):

SELECT ‘EASTER’ || CAST (EXTRACT (YEAR FROM CURRENT_DATE) AS CHAR(4)) AS SEASON …

Переменные и константы:

SELECT

ACOLUMN,

BCOLUMN,

CURRENT_USER, /* контекстная переменная */

‘Jaybird’ AS NICKNAME …

/* константа времени выполнения */

Все столбцы таблицы:

SELECT * …

Режимы выборки:

SELECT FIRST 5 SKIP 100 ACOLUMN, BCOLUMN …

/* это не будет иметь смысла при отсутствии в дальнейшем предложения ORDER BY */

Выражения и константы в качестве выходных полей

Константы или выражения — которые могут включать, а могут и не включать имя столбца- могут возвращаться только как неизменяемые, вычисляемые в момент выполнения поля. Такому столбцу должно назначаться имя, уникальное среди имен

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

Возьмем предыдущий пример:

SELECT ‘EASTER’ || CAST (EXTRACT (YEAR FROM CURRENT_DATE) AS CHAR(4)) AS SEASON …

В 2004 году этот алиас столбца будет возвращен для каждой строки набора в виде:

SEASON

======

EASTER2004

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

! ! !

ПРИМЕЧАНИЕ. Константы типа BLOB и массивы не могут быть использованы для выходных полей времени выполнения.

. ! .

О выражениях и функциях читайте в следующей главе.

FROM <таблица-или-процедура-или-просмотр>

Предложение FROM задает источник данных, который может быть таблицей, просмотром или хранимой процедурой, имеющей выходные аргументы. Если оператор включает соединение двух или более структур, то предложение FROM задает структуру, находящуюся в левой части. Другие таблицы добавляются в спецификацию при использовании последующих предложений ON (СМ. разд. «JOIN <спецификация> «).

В следующих примерах предложения FROM добавляются к спецификациям SELECT предыдущих примеров:

SELECT COLUMN1, COLUMN2 FROM ATABLE . . .

SELECT

TABLEA.ID,

TABLEA.BOOK_TITLE,

TABLEB.CHAPTER_TITLE,

CURRENT_TIMESTAMP AS RETRIEVE_DATE

FROM TABLEA . . .

SELECT MAX(COST * QUANTITY) AS BEST_SALE

FROM SALES …

SELECT ‘EASTER’||CAST(EXTRACT(YEAR FROM CURRENT_DATE) AS CHAR(2))

AS SEASON

FROM RDB$DATABASE ;

SELECT ACOLUMN, BCOLUMN, CURRENT_USER, ‘Jaybird’ AS NICKNAME

FROM MYTABLE …

Синтаксис внутреннего соединения SQL-89

Firebird обеспечивает поддержку устаревшего синтаксиса неявного внутреннего соединения SQL-89. Например:

SELECT

TABLEA.ID,

TABLEA.BOOK_TITLE,

TABLEB.CHAPTER_TITLE,

CURRENT_TIMESTAMP AS RETRIEVE_DATE

FROM TABLEA, TABLEB …

По разным причинам вам не следует использовать этот синтаксис в новых приложениях (см. главу 22).

Что это за таблица RDB$DATABASE?

RDB$DATABASE является системной таблицей, содержащей одну и только одну строку, которая хранит сведения заголовочной информации о базе данных. Что там находится, неважно для пользователей Firebird. Тот факт, что там всегда содержится одна строка — ни больше, ни меньше — делает эту таблицу удобной, когда мы хотим найти значение на сервере, которое не хранится ни в таблице, ни в просмотре, ни в хранимой процедуре.

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

SELECT GEN_ID(MyGenerator, 1) FROM RDB$DATABASE;

В РСУБД Oracle для аналогичных целей используется таблица DUAL.

JOIN <спецификация>

Используйте это предложение, чтобы добавить имена и условия соединения для второго и каждого последующего потока данных (таблица, просмотр или хранимая процедура выбора), который объединяется в многотабличном операторе SELECT — одно предложение JOIN … ON для каждого исходного набора. Синтаксис и использование JOIN подробно обсуждается в главе 22. Следующий оператор иллюстрирует простое внутреннее соединение между двумя таблицами из предыдущего примера:

SELECT

TABLEA.ID,

TABLEA.BOOK_TITLE,

TABLEB.CHAPTER_TITLE,

CURRENT_TIMESTAMP AS RETRIEVE_DATE

FROM TABLEA

JOIN TABLEB

ON TABLEA.ID = TABLEB.ID_В …

Алиасы таблиц

В том же фрагменте оператора идентификаторы таблиц могут быть заменены на алиасы таблиц, например:

SELECT

T1.ID,

T1.BOOK_TITLE,

T2.CHAPTER_TITLE,

CURRENT_TIMESTAMP AS RETRIEVE_DATE

FROM TABLEA T1

JOIN TABLEB T2

ON T1.ID = T2.ID_B …

Использование алиасов таблиц в многотабличных запросах подробно рассматривается в главе 22.

WHERE <условия-поиска>

Условия поиска, ограничивающие выводимые строки, размещаются в приложении WHERE. Условия поиска могут изменяться от условия простого соответствия для одного столбца до сложных условий, включающих выражения, предикаты AND, OR и NOT, преобразование типов, условия наборов символов и последовательностей сортировки и многое другое.

Предложение WHERE является фильтрующим предложением, определяющим, какие строки являются кандидатами для включения в выходной набор. Те строки, которые не были исключены условиями поиска в предложении WHERE, могут быть готовы для передачи инициатору запроса или они могут передаваться для последующей обработки, упорядочения на основании предложения ORDER BY С объединением или без объединения на основании предложения GROUP BY.

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

SELECT COLUMN 1, C0LUMN2 FROM ATABLE

WHERE ADATE BETWEEN ‘2002-12-25’ AND ‘2004-12-24’…

/**/

SELECT TL.ID, T2.TITLE, CURRENT_TIMESTAMP AS RETRIEVE_DATE

FROM TABLEA

JOIN TABLEB

ON TABLEA.ID = TABLEB.ID_B

WHERE TABLEA.ID = 99 ;

/**/

SELECT MAX(COST * QUANTITY) AS BEST_SALE

FROM SALES

WHERE SALES_DATE > ‘31.12.2003’…

Глава 21 посвящена выражениям и предикатам, используемым в условиях поиска.

Параметры в предложении WHERE

Интерфейсы доступа к данным, реализованные в API Firebird, имеют возможность обрабатывать константы в условиях поиска как заменяемые параметры. Следовательно, приложение может создавать оператор с динамическими условиями поиска в предложении WHERE, значения которых можно устанавливать непосредственно перед выполнением запроса. Такая возможность иногда называется динамическим связыванием.

Подробности см. в одном из следующих разд. «Использование параметров».

GROUP BY <список-группируемых-столбцов>

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

Следующий простой пример иллюстрирует группирующий запрос. Агрегатная SQL — функция SUMO используется для вычисления общего количества продаж для каждого типа продукции:

SELECT PRODUCT_TYPE, SUM(NUMBER_SOLD) AS SUM_SALES

FROM TABLEA

WHERE SERIAL_NO BETWEEN ‘A’ AND ‘K’

GROUP BY PRODUCT_TYPE;

Результат может быть похожим на следующий:

PRODUCT TYPE SUM SALES

Gadgets 174

Whatsits 25

Widgets 117

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

! ! !

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

. ! .

Обобщающие выражения обсуждаются в главе 21. Подробную информацию о предложении GROUP BY см. в главе 23.

HAVING <предикат-группирования>

Необязательное предложение HAVING может быть использовано вместе со спецификацией группирования для включения или исключения строк или групп, как это делает предложение WHERE, ограничивая набор строк. Часто в группирующих запросах предложение HAVING может заменить предложение WHERE. При этом, поскольку HAVING оперирует с промежуточным набором, созданным в качестве входа для спецификации GROUP BY, может оказаться более экономичным использование условия WHERE для ограничения количества строк и условия HAVING для ограничения количества групп.

Изменим предыдущий пример, добавив предложение HAVING для получения только тех PRODUCT_TYPE, которые имели количество продаж больше 100:

SELECT PRODUCT_TYPE, SUM(NUMBER_SOLD) AS SUM_SALES

FROM TABLEA

WHERE SERIAL_NO BETWEEN ‘A’ AND ‘K’

AND PRODUCT_TYPE = ‘WIDGETS’

GROUP BY PRODUCT_TYPE

HAVING SUM(NUMBER_SOLD) > 100;

Вывод будет таким:

PRODUCT TYPE SUM SALES

Widgets 117

UNION <выражение-выбора>

Наборы UNION формируются объединением двух или более спецификаций запросов, которые могут использовать различные таблицы, в один выходной набор. Единственное ограничение — выходные столбцы в каждой выходной спецификации должны соответствовать по степени, типу и размеру. Это означает, что в каждом выходе должно быть то же количество столбцов в том же порядке слева направо, и каждый столбец должен быть совместим по типу данных и размеру.

По умолчанию UNION убирает дубликаты в финальном выходном наборе. Для сохранения всех дубликатов добавьте ключевое слово ALL^[71].

Наборы UNION подробно обсуждаются в главе 23.

PLAN <выражение-плана>

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

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

Планы запросов и синтаксис выражений плана обсуждаются в разд. «Тема оптимизации» главы 22.

ORDER BY <список-столбцов>

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

SELECT EMP_NO, LAST_NAME, FIRST_NAME FROM EMPLOYEE

ORDER BY LAST_NAME, FIRST_NAME;

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

SELECT EMP_NO, LAST_NAME, FIRST_NAME FROM EMPLOYEE

ORDER BY 2, 3;

Обратите особое внимание на индексы для столбцов, которые будут использованы для сортировки (см. главу 18). Подробнее о синтаксисе и проблемах см. в главе 23.

Предложение FOR UPDATE

Его синтаксис:

[FOR UPDATE [OF col1 [,col2..]] [WITH LOCK]]

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

Необязательное внутреннее предложение OF <список-столбцов> может быть использовано для задания списка присутствующих в курсоре полей, которые могут быть изменены.

* В приложениях ESQL оператор DECLARE CURSOR используется для объявления именованного курсора. Подробную информацию см. в документации по InterBase 6.0 «Embedded SQL».

¦- Приложения интерфейса DSQL должны использовать функцию isc_dsqi_set_ cursor name для получения именованного курсора и осмысленно использовать FOR UPDATE. Более подробную информацию см. в InterBase API Guide.

Динамические приложения

Поскольку в DSQL отсутствует FETCH как элемент языка, приложения реализуют его с помощью вызова функции API С именем isc_dsql_fetch.

API «знает» порядок и формат выходных полей, потому что динамическое приложение должно передавать ему описательную структуру- называемую расширенной областью дескрипторов SQL (Extended SQL Descriptor Area, XSQLDA). Одна структура XSQLDA содержит массив описателей сложных переменных, называемых SQLVAR, по одному на каждое выходное поле.

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

Некоторые приложения API реализуют именованные курсоры и используют поведение TOR UPDATE, однако большинство этого не делают.

Вложенное предложение WITH LOCK

Firebird 1.5 вводит необязательное расширение WITH LOCK, используемое с/без предложения FOR UPDATE, для поддержки ограниченного уровня явной пессимистической блокировки (pessimistic locking) на уровне строки. Пессимистическая блокировка является прямой противоположностью архитектуры транзакций в Firebird и добавляет запутанность. Ее использование рекомендуется только тем разработчикам, которые хорошо понимают, как параллельная работа многих пользователей реализована в Firebird. Пессимистическая блокировка обсуждается в главе 27.

Запросы, подсчитывающие строки

Среди некоторых программистов существует закрепившаяся практика разработки приложений, которым нужно выполнить подсчет строк в выходном наборе. В Firebird не существует быстрого надежного способа получения количества строк, возвращаемых в выходном наборе. Поскольку Firebird имеет многоверсионную архитектуру, у него нет механизма «узнавать» количество строк в постоянных таблицах. Если приложению требуется количество строк, оно может получить приблизительное значение с использованием запроса SELECT COUNT (*).

Запросы SELECT COUNT(*)

Оператор SELECT с вызовом функции COUNT() на месте идентификатора столбца вернет приблизительную мощность набора, определенного в предложении WHERE. Функция COUNT() принимает практически все в качестве входного аргумента: идентификатор столбца, список столбцов, символ *, который представляет «все столбцы», и даже константу.

Например, все следующие операторы эквивалентны или близки. При этом SELECT COUNT(<имя-некоторого-столбца>) не включает в счетчик строки, где <имя-некоторого-столбца> имеет значение NULL:

SELECT COUNT (*) FROM ATABLE WHERE COL1 BETWEEN 40 AND 75;

SELECT COUNT (COL1) FROM ATABLE WHERE COL1 BETWEEN 40 AMD 75;

SELECT COUNT (COL1, COL2, COL3) FROM ATABLE WHERE COL1 BETWEEN 40 AND 75;

SELECT COUNT 1 FROM ATABLE WHERE COL1 BETWEEN 40 AND 75;

SELECT COUNT (‘Sticky toffee’) FROM ATABLE WHERE COL1 BETWEEN 40 AND 75;

COUNT(*) является очень дорогой операцией, потому что она может работать только пройдя по всему набору данных и точно подсчитав каждую строку, которая видима как подтвержденная для текущей транзакции. Это число должно трактоваться как «грубый счетчик», потому что может оказаться неверным, если другая транзакция подтверждает работу.

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

Исключением является ситуация, когда COUNT (*) включается в выходной набор, который агрегируется на основании предложения GROUP BY. При этих условиях счетчик не будет дорогим — он будет рассчитываться для агрегированной группы в процессе выполнения агрегирования. Например:

SELECT COL1, SUM(COL2), COUNT(*) FROM TABLEA

GROUP BY COL1;

Подробности использования COUNT С агрегированием см. в главе 23.

Проверка существования

Не используйте SELECT COUNT(*) как способ проверки существования строк, соответствующих некоторому критерию. Такая техника часто обнаруживается в приложениях, которые были переведены в Firebird из основанных на файлах базах данных с блокировкой таблиц, таких как Paradox или MySQL. От этой техники нужно отказаться. Вместо этого используйте функциональный предикат EXISTS(), который был разработан для этих целей и является очень быстрым. См. в следующей главе подробности об EXISTS() и других функциональных предикатах.

Вычисления «следующего значения»

Другая техника, от которой нужно отказаться в Firebird, это использование COUNT(*) и прибавление единицы для «генерации» значения первичного ключа. Это ненадежно в любой многопользовательской СУБД, которая изолирует параллельные задачи. В Firebird это к тому же выполняется крайне медленно, потому что система управления таблицей не имеет «файла записей», которые могли бы быть подсчитаны методами управления файлами на компьютере.

Используйте генераторы для любых целей, которые преследуют уникальность числовых последовательностей. Подробнее о генераторах см .разд. «Генераторы» главы 9.

Варианты COUNT()

Результатом COUNT() никогда не будет NULL, потому что он подсчитывает строки. Если счетчик будет использован для пустого набора, он вернет ноль. Он никогда не может быть отрицательным.

COUNT(*) для таблицы подсчитывает все строки без проверки существования данных в столбцах. Оптимизатор может использовать индекс, если запрос содержит соответствующее условие WHERE.

Например, оператор

SELECT COUNT(*) FROM EMPLOYEE

WHERE LAST_NAME BETWEEN ‘A%’ AND ‘M%’;

может быть чуть менее дорогим, если существует индекс для LAST_NAME.

COUNT (имя-столбца) подсчитывает только строки, где имя-столбца не является NULL.

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

в COUNT (DISTINCT …), если столбец допускает значение NULL, все строки, содержащие в этом столбце NULL, исключаются из подсчета. Если вы должны их сосчитать, это может быть выполнено «хакерским» способом:

SELECT COUNT (DISTINCT TABLE.COLX) +

(SELECT COUNT(*) FROM RDB$DATABASE

WHERE EXISTS(SELECT * FROM TABLE T

WHERE T.COLX IS NULL))

FROM TABLE

Оператор INSERT

Оператор INSERT используется для добавления строк в одну таблицу. SQL не позволяет в одном операторе INSERT добавлять строки более чем в одну таблицу.

При некоторых условиях оператор INSERT может работать с просмотрами. Обсуждение просмотров, для которых можно применять добавление данных в лежащие в основе просмотра таблицы, см. в главе 24.

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

Используйте следующую форму для добавления списка констант:

INSERT INTO имя-таблицы | имя-просмотра (<список столбцов>)

VALUES (<соответствующей список значений>)

Следующая форма используется для добавления из встроенного запроса:

INSERT INTO <таблица> (<список столбцов>)

SELECT [[FIRST m] [SKIP n]] <соответствующий список значений из другого набора>

[ORDER BY <встроенный столбец (столбцы)> [DESC]]

В следующем примере предложение INSERT INTO определяет входной набор для таблицы TABLEB, а предложение SELECT определяет соответствующий встроенный запрос к таблице TABLEA для получения значений для входного набора:

INSERT INTO TABLEB(COLA, COLB, COLC)

SELECT COL1, COL2, COL3 FROM TABLEA;

! ! !

ПРИМЕЧАНИЕ. He существует возможности добавлять данные во встроенный запрос.

. ! .

Добавление данных в столбцы BLOB

Техника INSERT INTO … SELECT напрямую передает столбец BLOB В столбец BLOB. Как правило, если вам нужно добавить столбец BLOB как часть списка VALUES(), он должен конструироваться клиентским приложением с использованием функций и структур API. В приложениях DSQL такие данные обычно передаются в виде потоков (stream). Размер сегмента может быть проигнорирован везде, кроме приложений ESQL.

При этом если вы передаете в VALUES() данные для BLOB В виде текста, Firebird примет символьную строку в качестве ввода, например:

INSERT INTO ATABLE (BLOBMEMO)

VALUES (‘Now is the time for all good men to come to the aid of the party’);

Эта возможность будет подходящей при условии, что сохраняемый текст никогда не превысит 32 767 байтов (или 32 765, если вы помещаете поле VARCHAR в BLOB). Может показаться, что для многих интерфейсов программирования подобная проблема не существует, потому что они не могут обрабатывать такие большие строки. Однако, поскольку Firebird принимает выражения конкатенации строк SQL, такие как MYVARCHARI 11 MYVARCHAR2, следует принять меры по защите входных строк от переполнения.

Добавление в столбцы массивов

В приложениях со встроенным SQL (ESQL) возможно конструирование оператора SQL для добавления целого массива в столбец массива. Могут появиться ошибки, если данные не полностью заполняют массив.

В DSQL вовсе нет возможности добавлять данные в столбцы массивов. Необходимо реализовывать пользовательский метод в приложении или в коде компонента, который будет вызывать API-функцию isc_array_put_siice.

Использование INSERT для автоматических полей

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

* столбец определен с предложением COMPUTED BY;

* столбец или домен, на котором он основан, включает предложение DEFAULT;

* для таблицы был создан триггер BEFORE INSERT для автоматического заполнения столбца.

Автоматические поля могут воздействовать на тот способ, каким вы формулируете операторы INSERT для таблицы.

Столбцы COMPUTED BY

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

CREATE TABLE EMPLOYEE (

EMP_NO INTEGER NOT NULL PRIMARY KEY,

FIRST_NAME VARCHAR (15),

LAST_NAME VARCHAR(20),

BIRTH_COUNTRY VARCHAR(30) DEFAULT ‘TAIWAN’,

FULL_NAME COMPUTED BY FIRST_NAME || ‘ ‘ || LAST_NAME);

COMMIT;

INSERT INTO EMPLOYEE (EMP_NO, FIRST_NAME, LAST_NAME, FULL_NAME)

VALUES (99, ‘Jiminy’, ‘Cricket’, ‘Jiminy Cricket’);

Столбцы, имеющие значение no умолчанию

Если столбец определен со значением по умолчанию, то это значение будет работать только при добавлении и только если этот столбец отсутствует в списке входных столбцов. Если немного изменить оператор добавления в предыдущем примере, то в столбец BIRTH_COUNTRY будет записано значение ‘TAIWAN’:

INSERT INTO EMPLOYEE (EMP_NO, FIRST_NAME, LAST_NAME)

VALUES (99, ‘Jiminy’, ‘Cricket’);

COMMIT;

SELECT * FROM EMPLOYEE WHERE EMP_NO = 99;

EMP_NO FIRST_NAME LAST_NAME BIRTH_COUNTRY FULL_NAME

99 Jiminy Cricket TAIWAN Jiminy Cricket

Значения по умолчанию никогда не заменяют значений NULL:

INSERT INTO EMPLOYEE (EMP_NO, FIRST_NAME, LAST_NAME, BI RTH_COUNTRY)

VALUES (100, ‘Maria’, ‘Callas’, NULL);

COMMIT;

SELECT * FROM EMPLOYEE WHERE EMP_NO = 100;

EMP_NO FIRST_NAME LAST_NAME BIRTH_COUNTRY FULL_NAME

100 Maria Callas Maria Callas

Если вы разрабатываете приложения с использованием компонентов, которые генерируют операторы INSERT из спецификаций столбцов операторов SELECT для наборов данных — например, Delphi или JBuilder — учитывайте такое поведение, Если ваш компонент не поддерживает метод получения значений по умолчанию с сервера, может оказаться необходимым изменить оператор, записывающий данные.

Триггеры BEFORE INSERT

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

Это вовсе не означает, что вы всегда должны опускать поля, обрабатываемые триггером, во входном списке. Очень рекомендуется для поддержания целостности данных создавать триггеры, которые присваивают значения столбцам в случае, когда такие значения не задаются в операторе INSERT — особенно когда используется множество приложений и инструментов для доступа к вашей базе данных. Триггер должен проверять входное значение (например, NULL) и выполнять свои действия в соответствии с условиями.

В следующем примере первичный ключ OID заполняется в триггере:

CREATE TABLE AIRCRAFT (

OID INTEGER NOT NULL,

REGISTRATION VARCHAR(8) NOT NULL,

CONSTRAINT PK_AIRCRAFT

PRIMARY KEY (OID));

COMMIT;

/**/

SET TERM ^;

CREATE TRIGGER BI_AIRCRAFT FOR AIRCRAFT

ACTIVE BEFORE INSERT POSITION 0

BEGIN

IF (NEW.OID IS NULL) THEN

NEW.OID = GEN_ID(ANYGEH, 1) ;

END ^

SET TERM ;^

COMMIT;

/* */

INSERT INTO AIRCRAFT (REGISTRATION)

SELECT FIRST 3 SKIP 2 REGISTRATION FROM AIRCRAFT_OLD

ORDER BY REGISTRATION;

COMMIT;

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

INSERT IN AIRCRAFT (OID, REGISTRATION)

VALUES(1033, ‘ECHIDNA’);

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

SELECT GEN_ID(YOURGENERATOR, 1) FROM RDB$DATABASE;

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

Другие аспекты этой техники см. в главе 31.

Оператор UPDATE

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

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

Позиционированные операции в сравнении с поисковыми

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

Многие компоненты интерфейсов эмулируют позиционированные операции изменения и удаления, используя поисковое изменение с предложением WHERE, уникально определяющим строку. Такие однонаправленные или прокручиваемые классы наборов данных поддерживают «буфер текущей строки», который хранит или связан со столбцом и значением ключа той строки, которая была выбрана задачей пользователя для операции. Когда пользователь готов отправить запрос на изменение или удаление, компонент конструирует поисковый оператор INSERT или DELETE, который указывает на одну строку базы данных, используя первичный ключ (или любой другой уникальный список столбцов) в предложении WHERE.

! ! !

ВНИМАНИЕ! He все компоненты столь «сообразительны», чтобы определить наличие дубликатов строк в «живых» буферах. В таких продуктах задачей разработчика является убедиться в уникальности или найти любой другой способ защитить приложение от нежелаемого изменения множества строк.

. ! .

Использование оператора UPDATE

Оператор UPDATE имеет следующую основную форму:

UPDATE имя-таблицы | имя-просмотра

SET имя-столбца = значение [,имя-столбца = значение …]

[WHERE <условие-поиска> | WHERE CURRENT OF имя-курсора]

При поисковых изменениях, если не задано предложение WHERE, то изменения будут выполнены для каждой строки таблицы.

Предложение SET

Синтаксис предложения SET:

SET имя-столбца = значение [, имя-столбца = значение …]

Предложение SET представляет собой список, указывающий каждый изменяемый столбец вместе с новым присваиваемым ему значением. Новое значение должно соответствовать определению столбца по типу и размеру. Если столбец допускает пустое значение, ему также может быть присвоено значение NULL.

Значение может быть:

* константой корректного типа (например, SET COLUMNB = ’99’). Если для столбца указан набор символов, отличный от набора символов соединения, то заменяющее значение может быть преобразовано в этот указанный набор символов с помощью включения соответствующего дескриптора набора символов слева от константы. Дескриптор набора символов является именем набора символов, который начинается с символа подчеркивания, например:

SET COLUMNY = _ISO8859_1 ‘fricassee’

* идентификатором другого столбца в той же таблице, представленным с корректным типом данных. Например, SET COLUMNB = COLUMNX заменит текущее значение столбца COLUMNB на текущее значение столбца COLUMNX. При необходимости может быть использован дескриптор набора символов (см. ранее);

* выражением. Например, SET REVIEW_DATE = REVIEW_DATE + 14 изменяет значение столбца даты на две недели позже, чем текущее значение. Подробнее о выражениях см. главу 21;

* контекстной переменной сервера (например, SET DATE_CHANGED = CURRENT_DATE). Контекстные переменные описаны в главе 8;

* символом-заменителем параметра, соответствующим синтаксису, реализованному в коде приложения (например, для Delphi SET LAST_NAME = :LAST_NAME ИЛИ, для других интерфейсов приложений, SET LAST_NAME = ?);

* вызовом определенной пользователем функции (UDF). Например, SET BCOLUMN = OPPER(ACOLUMN) использует внутреннюю SQL-функцию UPPER для преобразования значения столбца ACOLUMN в верхний регистр и сохранения результата в BCOLUMN. Информацию об использовании функций см. в главе 21.

Предложение COLLATE может быть включено при модификации символьных столбцов (но не BLOB). для большинства наборов символов может оказаться необходимым использование одного из предыдущих примеров, поскольку последовательность сортировки по умолчанию (двоичная) обычно не поддерживает функцию UPPER(). Например, если ACOLUMN и BCOLUMN описаны с набором символов ISO8859_1 и используют испанский язык, то предложение SET должно быть следующим:

SET BCOLUMN = UPPER (ACOLUMN) COLLATION ES_ES

Подробнее о наборах символах и последовательностях сортировки см. главу 11.

Переключение значений

Будьте осторожны при «переключении» значений между столбцами. Выражение типа

. . .

SET COLUMNA = COLUMNB

приведет к тому, что текущее значение в столбце COLUMNA будет немедленно заменено текущим значением столбца COLUMNB. Если затем вы сделаете

SET COLUMNB = COLUMNA

то, поскольку старое значение столбца COLUMNA было потеряно, значения столбцов COLUMNB и COLUMNA останутся теми же, что и после первого переключения.

Для переключения значений вам нужен третий столбец, в котором будет «парковаться» значение из COLUMNA, пока вы не будете готовы назначить его столбцу

COLUMNB:

. . .

SET

COLUMNC = COLUMNA,

COLUMNA = COLUMNB, COLUMNB = COLUMNC

. . .

В SET вы можете использовать выражения, следовательно, при переключении двух целых значений возможно использование арифметических операций над двумя значениями. Предположим, что COLUMNA равняется 10, a COLUMNB 9:

. . .

SET

COLUMNB = COLUMNB + COLUMNA, /* COLUMNB теперь 19 */

COLUMNA = COLUMNB — COLUMNA, /* COLUMNA теперь 9 */

COLUMNB = COLUMNB — COLUMNA /* COLUMNB теперь 10 */

. . .

Всегда проверяйте ваши предположения при выполнении переключений!

Изменение столбцов BLOB

Изменение столбцов BLOB фактически полностью заменяет старое значение BLOB на новое. Старый указатель BLOB ID при изменении заменяется. Также:

* невозможно изменить BLOB путем конкатенации другого BLOB или строки с существующим BLOB;

* значение текстового BLOB может быть установлено с использованием строки в качестве ввода. Например, MEMO в следующем примере является текстовым BLOB:

UPDATE ATABLE

SET MEMO = ‘Friends, Romans, countrymen, lend me your ears: I come not to bury Caesar, but to praise him.’;

! ! !

ВНИМАНИЕ! Помните, что хотя столбцы BLOB не ограничены по размерам, строковые типы ограничены 32 765 байтами (VARCHAR) или 32 767 байтами (CHAR) — это байты, а не символы. Учтите это при конкатенации многобайтовых наборов символов.

. ! .

Изменение столбцов массивов

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

Не существует возможности изменять столбцы массивов в DSQL. Для изменения массивов необходимо в коде приложения или компонента реализовать пользовательские методы, которые вызывают функцию API isc_array_put_slice.

Значение по умолчанию для столбцов

Ограничения DEFAULT никогда не учитываются при выполнении операторов UPDATE.

Оператор DELETE

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

DELETE FROM имя-таблицы

[WHERE <предикаты-поиска>

| WHERE CURRENT OF имя-курсора]

Если не указано предложение WHERE, то будут удалены все строки таблицы.

Оператор EXECUTE

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

! ! !

ПРИМЕЧАНИЕ. Не путайте оператор EXECUTE с синтаксисом оператора EXECUTE STATEMENT, который поставляется в расширениях PSQL в Firebird 1.5 и выше и с оператором EXECUTE PROCEDURE В DSQL (описывается далее в разд. «Выполняемые процедуры»).

. ! .

Запросы, которые вызывают хранимые процедуры

Firebird поддерживает два стиля хранимых процедур: выполняемые процедуры и процедуры выбора (селективные процедуры). Подробности о различиях в технике написания и использования этих стилей процедур см. в главах 28-30.

Выполняемые процедуры

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

EXECUTE PROCEDURE ИМЯ-процедуры

[(<список входных значений>)

Следующий простой пример иллюстрирует вызов выполняемой процедуры, которая принимает два входных аргумента, выполняет некоторые действия на сервере и завершает работу:

EXECUTE PROCEDURE DO_IT(49, ’25-DEC-2004′);

В приложениях более мощным средством является использование параметров (см. разд. «Использование параметров») в операторах запросов, которые выполняют хранимые процедуры, например:

EXECUTE PROCEDURE DO_IT(:IKEY, :KEPORT_DATE) ;

или

EXECUTE PROCEDURE DO_IT(?, ?);

Процедуры выбора

Хранимые процедуры выбора способны возвращать многострочные наборы данных в ответ на специализированную форму оператора SELECT:

SELECT <список выходных столбцов>

FROM имя-процедуры [ (<список входных значений>) ]

[WHERE <предикаты поиска>]

[ORDER BY <список выходных столбцов>]

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

CREATE PROCEDURE GET_COFFEE_TABLE (IKEY INTEGER)

RETURNS (

BRAND_ID INTEGER,

VARIETY_NAME VARCHAR(40),

COUNTRY_OF_ORIGIN VARCHAR(30))

AS . . . . . .

Приложение получает выходной набор из хранимой процедуры следующим образом:

SELECT BRAND_ID, VARIETY_NAME, COUNTRY_OF_ORIGIN FROM GET_COFFEE_TABLE (5002) ;

Тот же самый пример с параметризованным входным аргументом:

SELECT BRAND_ID, VARIETY_NAME, COUNTRY_OF_ORIGIN FROM GET_COFFEE_TABLE(:IKEY);/* Delphi */

или

SELECT BRAND_ID, , VARIETY_NAME, COUNTRY_OF_ORIGIN FROM GET_COFFEE_TABLE(?);

Использование параметров

«Непараметризованный» запрос использует константы в выражениях для условий поиска. Например, в запросе

SELECT MAX(COST * QUANTITY)

AS BEST_SALE FROM SALES

WHERE SALESEDATE > ‘31.12.2003’ ;

будут обработаны те строки таблицы SALES, у которых дата в SALES_DATE более поздняя, чем последний день 2003 года.

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

Приложение DSQL может создать оператор с динамическими условиями поиска в предложении WHERE, один раз подготовить его, а затем присваивать параметрам значения один или много раз непосредственно перед каждым выполнением. Такую возможность иногда называют динамическим связыванием. Средства разработки приложений отличаются по тем способам, которыми они реализуют динамическое связывание параметров во включающем языке. В зависимости от того, какое средство разработки вы используете, параметризованная версия последнего примера может выглядеть несколько иначе, например, так:

SELECT MAX (COST * QUANTITY) AS BEST_SALE

FROM SALES

WHERE SALES_DATE > ? ;

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

API «знает» порядок и формат параметров, потому что приложение передает описательные структуры XSQLDA, которые содержат массив SQLVAR- дескрипторы переменных, описывающих каждый параметр, — и другие данные, описывающие массив в целом.

Delphi и другие объектно-ориентированные реализации API используют методы и свойства классов, чтобы скрыть от разработчика механизм, применяемый для создания и управления сырым оператором и дескрипторами. Другие средства разработки кодируют эти структуры иным образом. Оператор может передаваться на сервер приблизительно в таком виде:

INSERT INTO DATATABLE (DATAl, DATA2, DATA3, DATA4, DATA5,… другие столбцы)

VALUES (?, ‘?’, ‘?’, ?, ?, … другие значения);

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

Замечания для пользователей Delphi

Delphi, имеющее клеймо «made in Borland», как и InterBase, предшественник Firebird, при передаче переменных включающего языка реализует формат, который повторяет формат, используемый в PSQL для ссылки на локальные переменные в SQL- операторах и ESQL. Он требует, чтобы все параметры были явно именованы и начинались с символа двоеточия. В Delphi предыдущий простой пример может быть представлен в свойстве SQL объекта доступа к данным в следующем виде:

SELECT MAX(COST * QUANTITY) AS BEST_SALE

FROM SALES

WHERE SALES_DATE > :SALES_DATE ;

Один вызов метода PREPARE приведет к проверке оператора и передаче описания метаданных назад в клиентское приложение; объект доступа к данным позволяет позже присваивать значение параметру, используя локальный метод, который выполняет преобразование значения к формату, требуемому в Firebird:

aQuery.ParamByName (‘SALES_DATE’).AsDate := ALocalDateVariable;

Пакетные операции

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

Пакетные добавления

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

INSERT INTO DATATABLE(DATA1, DATA2, DATA3, DATA4, DATA5, . . . другие столбцы)

VALUES (‘x’, ‘у’, ‘z’, 99, ‘2004-12-25’, . . . другие значения);

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

INSERT INTO DATATABLE(DATA1, DATA2, DATA3, DATA4, DATA5, . . . другие столбцы)

VALUES (?, ‘?’, ‘?’, ?, ?, …. другие значения);

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

Предотвращение замедления пакетной операции

Два поведения могут привести к огромному объему пакетных операций, резко замедляющих выполнение.

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

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

Деактивация индексов

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

ALTER INDEX имя-индекса INACTIVE;

Когда большая пакетная операция закончится, реактивируйте и пересоздайте индексы:

ALTER INDEX имя-индекса ACTIVE;

Разбиение больших пакетов

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

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

! ! !

СОВЕТ. Когда вам нужно разделять огромные пакеты, часто хранимые процедуры являются способом это сделать. Вы можете использовать локальные переменные-счетчики, сообщения о событиях и возвращать значения для сохранения вызова процедуры с целью синхронизации с вызовами клиента.

. ! .

Операции DML и события изменения состояния

Firebird включает некоторые особенности, которые могут быть использованы при проектировании базы данных для реагирования на операции DML, которые изменяют состояние данных, — а именно выполнение операторов INSERT, UPDATE и DELETE.

Предложения действия ссылочной целостности

Триггеры ссылочной целостности являются модулями компилированного кода, создаваемыми ядром сервера, когда вы объявляете ограничение ссылочной целостности для ваших таблиц. Включив предложения действия ON UPDATE и ON DELETE В объявление ограничения FOREIGN KEY, вы можете задать одно из группы действий, которое будет выполняться при наступлении соответствующего события DML. Подробности см. в главе 17.

Пользовательские триггеры

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

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

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

Фазы событий DML

Синтаксис триггера разделяет пользовательские действия DML на две фазы: первая

фаза появляется до (BEFORE) события, а вторая после (AFTER) события.

* Фаза BEFORE дает возможность управлять преобразованием значений, которые являются входными в операторе DML, и определять значения по умолчанию гораздо более гибкими способами, чем это позволено в стандартном SQL-ограничении DEFAULT. Фаза BEFORE завершается перед тем, как начинают проверяться любые ограничения столбца, таблицы или ограничения целостности.

* В фазе AFTER ответные действия могут быть выполнены над другими таблицами. Обычно такие действия включают добавления, изменения или удаления данных других таблиц с использованием переменных NEW и OLD для обеспечения контекста текущей строки и операции. Фаза AFTER начинается после применения всех ограничений собственной таблицы. Триггеры AFTER не могут изменять значения в текущей строке собственной таблицы.

Табл. 20.1 описывает шесть фаз/событий пользовательских триггеров.

Таблица 20.1. Шесть фаз/событий пользовательских триггеров

Добавление	Изменение	Удаление
BEFORE INSERT	BEFORE UPDATE	BEFORE DELETE
AFTER INSERT	AFTER UPDATE	AFTER DELETE

Контекстные переменные NEW и OLD

Сервер делает доступными для триггеров два набора контекстных переменных. Один состоит из всех значений полей текущей строки, какими они были перед последним помещением этой строки в базу данных. Идентификаторы этого набора состоят из слова «OLD.», за которым следует идентификатор столбца. Аналогичным образом все новые значения имеют префикс «NEW.» перед каждым идентификатором столбца. Разумеется, «OLD.» не имеет смысла в триггерах добавления, a «NEW.» бессмысленно использовать в триггерах удаления.

Триггеры многих действий

В Firebird 1.5 и выше вы можете писать триггеры с условной логикой для всех событий (добавление, изменение и удаление) для одной из фаз- BEFORE или AFTER — в одном модуле триггера. Это долгожданное улучшение, которое уменьшает кодирование триггеров на две трети.

Несколько триггеров на событие

Другой полезной возможностью является использование нескольких триггеров для каждой комбинации фаза/событие. Синтаксис CREATE TRIGGER включает ключевое слово POSITION, принимающее целый аргумент, который может быть использован для установки начинающегося с нуля порядка, в котором будут выполняться триггеры для одной фазы.

Подробные инструкции, синтаксис и языковые расширения для создания триггеров см. в главе 31.

Пора дальше

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

ГЛАВА 21. Выражения и предикаты.

В алгебре выражение типа а + b = с может иметь решение «истина» или «ложь» при подстановке значений в a, b и с. Альтернативный вариант — если задано два значения из a, b, c, мы можем вычислить отсутствующее значение. Это и является выражением SQL — формула подстановки.

Выражения SQL предоставляют формальные компактные методы для вычисления, преобразования и сравнения значений. В этой главе мы подробно рассмотрим выражения в SQL Firebird.

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

Выражения

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

Для простого примера возьмем таблицу MEMBERSHIP, которая имеет столбцы FIRST_NAME, LAST_NAME и DATE_OF_BIRTH. Для получения списка, содержащего полное имя и дату рождения, мы можем использовать оператор, содержащий выражения для преобразования хранимых данных:

SELECT

FIRST_NAME ||’ ‘|| LAST_NAME AS FULL_NAME,

EXTRACT (MONTH FROM DATE_OF_BIRTH) ||’/’|| EXTRACT (DAY FROM DATE_0F_BIRTH)

AS BIRTHDAY

FROM MEMBERSHIP

WHERE FIRST_NAME IS NOT NULL AND LAST_NAME IS NOT NULL

ORDER BY 2;

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

В этом одном операторе мы используем три вида выражений SQL.

* Для первого поля FULL NAME используется оператор конкатенации (в SQL два символа вертикальной черты 11) для создания выражения, которое объединяет два поля базы данных, разделенные пробелами в одно.

* Для второго поля BIRTHDAY используется функция для выделения сначала месяца, а затем дня месяца из поля даты. В том же выражении опять используется оператор конкатенации для объединения вместе выделенных чисел в качестве даты рождения. День отделяется от месяца наклонной чертой.

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

В этом примере выражения были использованы:

* для преобразования найденных данных в выходные столбцы;

* для задания условий поиска в предложении WHERE оператора SELECT. Тот же подход может быть использован для условий поиска операторов UPDATE и DELETE.

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

* для задания условий проверки данных в ограничениях CHECK;

* для определения вычисляемых (COMPUTED BY) столбцов в операторах CREATE TABLE и ALTER TABLE;

* для преобразования или создания входных данных в процессе их сохранения в таблице при использовании операторов INSERT или UPDATE;

* для упорядочения или группирования выходных наборов;

* при установке во время выполнения условий определения вывода;

* в условиях потока управления в модулях PSQL.

Предикаты

Предикат — это просто выражение, которое утверждает некоторый факт о значении. Операторы SQL обычно проверяют предикаты во фразах WHERE и В выражениях CASE, ON является проверкой для предикатов JOIN, HAVING проверяет атрибуты в сгруппированном выводе. В PSQL операторы управления потоком выполнения проверяют предикаты в предложениях IF, WHILE и WHEN. Решения принимаются в соответствии с результатом вычисления предиката — истина или ложь.

Строго говоря, предикат может быть истинным, ложным и неопределенным. В SQL ложный и неопределенный результаты объединяются и трактуются как ложь. Иными словами, «если он не истинный, значит он ложный».

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

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

Возьмем такой простой оператор, где равенство = используется для проверки точного соответствия:

SELECT * FROM EMPLOYEE

WHERE LAST_NAME = ‘Smith’;

Это предикат «значением столбца LAST_NAME является ‘smith'». Сравниваются две константы (текущее значение столбца и строковый литерал) для проверки их равенства. Выбирая каждую строку из таблицы EMPLOYEE, сервер будет отбрасывать все, где предикат является ложным (значение отличается от ‘Smith’) или неопределенным (столбец имеет значение NULL, следовательно, он не может быть определен, как имеющий значение ‘Smith’ или не имеющий значение ‘Smith’).

Где проверяется истинность

Синтаксическими элементами, проверяющими истинность, являются:

* в DDL: CHECK для проверки условий достоверности данных;

* в SQL: WHERE (для условий поиска), HAVING и NOT HAVING (для условий выбора групп), ON (для условий соединения) и случаи проверки множества условий CASE, COALESCE и NULLIF;

* в PSQL: IF (универсальная проверка истина/ложь), WHILE (для проверки условий цикла) и WHEN (для проверки кодов исключения).

Утверждения

Часто условия, проверяемые в WHERE, IF и т.д., не

являются простыми предикатами, а группой нескольких предикатов, каждый из которых при вычислении делает вклад в вычисление общей истинности. Утверждение может состоять из одного предиката или из нескольких предикатов, связанных логическими операциями AND или OR. Каждый из этих предикатов сам может содержать вложенные предикаты. Окончательный результат вычисление истинности утверждения получается в результате процесса, который работает по направлению от внутренних предикатов к внешним. Каждый «уровень» должен быть вычислен в порядке своего приоритета, пока не будет возможным получить окончательное значение утверждения.

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

SELECT * FROM EMPLOYEE

WHERE (

(HIRE_DATE > CURRENT_DATE — 366)

AND (SALARY BETWEEN 25000.00 AND 39999.99));

Строки, для которых одно утверждение истинно, а другое ложно, будут отбрасываться.

Первый предикат (HIRE_DATE > CURRENT_DATE — 366) использует выражение, состоящее из переменной и операции вычисления значения, которое будет сравниваться со значением столбца. В этом случае утверждение использует оператор- утверждение будет истинным, если значение столбца будет больше, чем значение, полученное из выражения.

Второй предикат использует другой оператор. Ключевое слово BETWEEN задает проверку «больше или равно значению в левой части и меньше или равно значению в правой части».

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

Решение, что является истинным

На рис. 21.1 показаны возможные результаты вычисления двух предикатов из предыдущего примера.

В нашем примере вначале проверяется (HIRE_DATE > CORRENT_DATE — 366), потому что это самый левый предикат. Если бы у него были вложенные предикаты, то сначала проверялись бы они. Ни для одного из предикатов нет проверки на NULL, но мы включили сюда тот случай, когда встречается пустое («неизвестное») значение в проверяемых данных, что приведет к результату «ложь», поскольку проверка не может вернуть истину. Должна быть доказана истинность предикатов, чтобы они считались истинными.

Если NULL встречается в HIRE DATE, то проверка немедленно прекращается и возвращает ложь^[72]. Связка AND означает: два предиката, соединенные операцией AND, не могут давать результат истина, если один из них является ложным, следовательно, нет необходимости выполнять проверку второго предиката.

Если проверяемые данные не являются NULL, ТО следующей является проверка, верно ли, что значение больше указанной константы. Если нет, проверка прекращается. Другими словами, NULL и ложь имеют один и тот же эффект, поскольку оба не являются истиной.

Рис. 21.1. Вычисление истинности

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

Символы, используемые в выражениях

Табл. 21.1 описывает символы, которые могут появляться в выражениях SQL.

Таблица 21.1. Элементы выражений SQL

Элемент	Описание
Имя столбца	Идентификаторы столбцов из указанных таблиц, представляющих поле, используемое в вычислении, или сравнении, или в качестве условия поиска. На любой столбец базы данных может быть ссылка в выражении за исключением столбцов типа массива. (Исключение: любой столбец, являющийся массивом, может проверяться на is [NOT] NULL)
Элементы массива	На элементы массива может быть ссылка в выражении
Имена столбцов только для вывода	Во время выполнения идентификаторы задают вычисляемые столбцы или алиасы столбцов базы данных
Ключевое слово AS	Используется (необязательно) как маркер для имени только для выходного столбца списка столбцов в SELECT
Арифметические операторы	Символы +, -, * и / используются для вычисления значений
Логические операторы	Зарезервированные слова NOT, AND и OR используются в простых условиях поиска или при комбинировании простых условий поиска для создания сложных предикатов
Операторы сравнения	<, >, <=, >=, = и <> используются для сравнения утверждений
Другие операторы сравнения	LIKE, STARTING WITH, CONTAINING, BETWEEN, и IS [NOT] NULL
Операторы существования	Предикаторы, используемые для проверки существования значения в наборе, IN может быть использован с наборами констант или со скалярными подзапросами, EXISTS, SINGULAR, ALL, ANY и SOME могут быть использованы только с подзапросами
Оператор конкатенации	Пара из вертикальных черт (\|\|) используется для соединения символьных строк. Обратите внимание, что символы + и & не являются символами конкатенации в стандарте SQL
Константы	Числа или заключенные в апострофы строковые литералы, такие как 507 или ‘Tokyo’, которые могут быть включены в вычисления или сравнения в качестве полей времени выполнения
Литералы даты	Выражения, подобные строковым литералам, заключенным в апострофы, которые могут быть интерпретированы как значения даты, времени или даты-времени в операциях EXTRACT, SELECT, INSERT и UPDATE. Литералами даты могут быть предварительно определенные литералы (‘TODAY’, ‘NOW’ ‘YESTERDAY’, ‘TOMORROW’) или подходящие строки даты и времени, как описано в главе 10. В диалекте 3 литералы даты обычно требуют преобразования (CAST) в допустимый тип даты/времени при использовании в выражениях EXTRACT и SELECT
Внутренние контекстные переменные	Получаемые с сервера переменные, которые возвращают зависимые от контекста значения, такие как серверное время или идентификатор текущей транзакции
Подзапросы	Внутренние операторы SELECT, которые возвращают единственное (скалярное) значение для вывода или для сравнения в предикате
Локальные переменные	Именованные хранимые процедуры, триггеры или (в ESQL) переменные приложений, содержащие значения, которые могут изменяться в процессе выполнения
Идентификаторы функций	Идентификаторы внутренних или внешних функций в функциональных выражениях
CAST(значение AS тип-данных)	Функциональные выражения, явно преобразующие значение одного типа данных в другой тип данных
Условные выражения	Функции, объявляющие два или более взаимоисключающих условия для одного столбца, начинающиеся с ключевого слова CASE, COALESCE или NULLIF
Круглые скобки	Используются для группирования выражений. Операции внутри скобок выполняются перед операциями вне скобок. Когда используются вложенные скобки, вначале вычисляются значения самых внутренних выражений, затем вычисления перемещаются вверх по уровням вложенности
Предложение COLLATE	Может быть применено со значениями CHAR и VARCHAR, чтобы использовать строковые сравнения в указанной последовательности сортировки

Операторы SQL

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

Приоритет операторов

Приоритет определяет порядок, в котором операторы и создаваемые ими значения вычисляются в выражении.

Когда выражение содержит несколько операторов одного и того же типа, операторы вычисляются слева направо, если только не существует конфликта, когда два оператора одного и того же типа воздействуют на одни и те же значения. Когда возникает конфликт, приоритет операторов определяется типом. В табл. 21.2 показаны приоритеты типов операторов Firebird от высшего к низшему.

Таблица 21.2. Приоритеты типов операторов

Тип оператора	Приоритет	Объяснение
Конкатенация	1	Строки объединяются до выполнения любых других операций
Арифметический	2	Арифметические операции выполняются после конкатенации строк, но перед выполнением сравнений и логических операций
Сравнение	3	Операции сравнения вычисляются после конкатенации строк и выполнения арифметических операций, но до логических операций
Логический	4	Логические операции выполняются после всех других операций. Приоритет: когда условия поиска являются комбинированными, порядок вычислений определяется приоритетом используемых операторов, NOT вычисляется перед AND, а AND вычисляется перед OR. Круглые скобки могут использоваться для изменения порядка вычисления

Оператор конкатенации

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

SELECT Last_name ||’, ‘ || First_Name AS Full_Name FROM Membership;

! ! !

ПРИМЕЧАНИЕ. Firebird более требователен к переполнению строк, чем его предшественники. Он проверит длину входных столбцов и заблокирует конкатенацию, если результирующий размер потенциально может превысить лимит для VARCHAR (32 765 байтов).

. ! .

Арифметические операции

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

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

Таблица 21.3. Приоритеты арифметических операций

Оператор	Назначение	Приоритет
*	Умножение	1
/	Деление	2
+	Сложение	3
—	Вычитание	4

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

. . .

SET COLUMN_A = 1/((COLUMN_B * COLUMN_C/4) — ( (COLUMN_D / 10) + 28))

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

Операторы сравнения

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

Таблица 21.4. Приоритеты операторов сравнения

Оператор	Назначение	Приоритет
=	Равно, идентично	1
<>, !=, ~=, ^=	Не равно	2
>	Больше	3
<	Меньше	4
>=	Больше или равно	5
<=	Меньше или равно	6
!>, ~>, ^>	Не больше	7
!<, ~<, ^<	Не меньше	8

Сравнения, которым встречается NULL В левой или правой части оператора, всегда следуют правилам логики SQL, вычисляя результат сравнения как NULL и возвращая ложь, например:

IF (YEAR_OF_BIRTH < 1950)

Это сравнение вернет ложь, если YEAR_OF_BIRTH равняется 1950, больше него или имеет значение NULL.

Подробное обсуждение NULL см. в разд. «Обсуждение NULL».

Пары сравниваемых значений могут быть столбцами, константами или вычисляемыми выражениями^[73], они должны быть вычислены в том же типе данных. Функция CAST() может быть использована для трансляции в тип данных, совместимый для сравнения.

Арифметические предикаты, использующие эти символы, не требуют пояснения. При этом символьные проверки также могут их использовать. Проверки, использующие сравнения = и <>, понятны. Следующий оператор использует оператор >=, чтобы вернуть все строки, где LAST_NAME равен тестируемой строке, а также те строки, где LAST NAME рассматривается в алфавитно-цифровом порядке, как «больше, чем»:

SELECT * FROM EMPLOYEE

WHERE LAST_NAME >= ‘Smith’;

В таблице EMPLOYEE нет значений ‘Smith’, HO запрос вернет ‘Stansbury’, ‘Steadman’ и так далее вплоть до ‘Young’. База данных Employee в этом примере использует набор символов NONE, в котором символы в нижнем регистре имеют приоритет перед символами в верхнем регистре. В нашем примере строка ‘SMITH’ не будет выбрана, потому что искомая строка ‘SM’ (83 + 77) будет меньше, чем ‘SM’ (83 + 109).

Наборы символов и последовательности сортировки

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

Последовательность сортировки по умолчанию для каждого набора символов — та последовательность, чье имя соответствует имени набора символов, — является бинарной. Двоичная последовательность сортировки определяет возрастание по цифровым кодам символа в той системе, в которой он кодирован (ASCII, ANSI, Unicode и т.д.). Альтернативные последовательности сортировки обычно перекрывают порядок по умолчанию, чтобы соблюдать локальные или специальные правила, такие как нечувствительность к регистру или упорядочение по словарю^[74].

Другие предикаты сравнения

Предикаты BETWEEN, CONTAINING, LIKE и STARTING WITH, представленные в табл. 21.5, имеют одинаковый приоритет при вычислениях в операторах сравнения, описанных

в табл. 21.4. Если они конфликтуют друг с другом, то вычисление осуществляется строго слева направо.

Таблица 21.5. Другие предикаты сравнения

Предикат	Назначение
BETWEEN … AND …	Значение попадает во включающий диапазон значений
CONTAINING	Строковое значение содержит указанную строку. Сравнение является независимым от регистра
IN	Значение присутствует в указанном наборе*
LIKE	Равенство указанной строке с шаблонными подстановками
STARTING WITH	Строковое значение начинается с указанной строки

* Наиболее эффективной является ситуация, когда набор содержит небольшое количество констант. Набор не может превышать 1500 элементов. (См. разд. «Предикаты существования».)

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

SELECT * FROM EMPLOYEE

WHERE HIRE_DATE BETWEEN ‘01.01.1992’ AND CURRENT_TIMESTAMP;

BETWEEN будет использовать возрастающий индекс по искомому столбцу, если таковой доступен.

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

Следующий пример

SELECT * FROM PROJECT

WHERE PROJ_NAME CONTAINING ‘ Map ‘ ;

возвращает две строки проекта: ‘AutoMap’ и ‘MapBrowser port’. Следующий пример

SELECT * FROM SALARY_HISTORY

WHERE CHANGE_DATE CONTAINING 93;

возвращает все строки, где датой является год 1993.

! ! !

ВНИМАНИЕ! В некоторых релизах CONTAINING является непредсказуемым, когда используется для BLOB, чей размер больше 1024 байт. Это определено как ошибка и будет вскоре исправлено в следующем после 1.5 релизе.

. ! .

IN принимает в качестве аргумента список значений и возвращает все строки, где значение столбца в левой части равно любому значению в множестве, например:

SELECT * FROM EMPLOYEE

WHERE FIRST_NAME IN(‘Pete’, ‘Ann’, ‘Roger’);

NULL не может быть включен в множество поиска.

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

! ! !

ВНИМАНИЕ! Общей ошибкой «чайников» является трактовка предиката IN (<значение>) как если бы он был эквивалентным предикату =<значение>, потому что оба предиката логически эквивалентны в том смысле, что оба возвращают один и тот же результат. При этом IN не использует индексы. Поскольку среди равных поисков обычно лучшим является тот, который оптимизирован по индексу, использование IN является плохим решением с точки зрения производительности.

. ! .

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

* Символ % может быть подставлен в строку поиска для представления любого количества любых символов, в том числе и нулевого количества, например:

LIKE ‘%mit%’

вернет истину для таких строк, как ‘blacksmith’, ‘mitgenommen’, а также и ‘mit’.

* Символ подчеркивания (_) может быть вставлен в строку поиска для представления одного неопределенного символа. Например, следующее условие задает поиск записей, где фамилия может быть ‘Smith’, ‘Smyth’ или другой, похожей на шаблон:

LIKE ‘Sm_th’

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

Например, скажем, вам нужно использовать оператор LIKE для поиска всех имен системных таблиц. Предположим, что все имена системных таблиц содержат, по меньшей мере, один символ подчеркивания- а это почти правда! Вы решили использовать символ # в качестве символа отмены. Вот что вам нужно сделать:

SELECT RDB$RELATION_NAME FROM RDB$RELATIONS

WHERE RDB$RELATION_NAME LIKE ‘%#_%’ ESCAPE ‘#’;

Поиски LIKE не используют индекс. При этом предикат, использующий LIKE ‘ваша строка%’, будет преобразован в предикат STARTING WITH, который будет использовать индекс, если тот доступен.

Предикаты STARTING WITH являются чувствительными к регистру. Они используют правила соответствия байтов применяемого набора символов и последовательности сортировки. При необходимости они могут использовать аргумент COLLATION для поиска с применением конкретной последовательности сортировки.

Следующий пример

SELECT LAST_NAME, FIRST_NAME FROM EMPLOYEE

WHERE LAST_NAME STARTING WITH ‘Jo’;

вернет строки, где фамилиями будут ‘ Johnson’, ‘ Jones ‘, ‘ Joabim’ и др.

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

SELECT FAM_NAME, ERSTE_NAME FROM ARBEITNEHMER

WHERE COLLATE DE_DE FAM_NAME STARTING WITH ‘ Schmi ‘ ;

STARTING WITH будет использовать индекс, если он доступен.

Логические операторы

Firebird предоставляет три логических оператора, которые могут работать с другими предикатами разными способами.

* NOT задает отрицание условия поиска, к которому он применяется. Он имеет наивысший приоритет.

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

* OR создает сложный предикат, объединяет два или более предикатов, из которых хотя бы один должен быть истинным, чтобы был истинным весь предикат. Является последним по приоритету. По умолчанию Firebird 1.5 использует сокращенную булеву логику для определения значения предиката OR. Как только один из внутренних предикатов вернет истину, вычисления останавливаются, и весь предикат вернет истину^[75].

Вот пример логического предиката:

COLUMN_l = COLUMN_2

OR ( (COLUMN_1 > COLUMN_2 AND COLUMN_3 < COLUMN_1)

AND NOT (COLUMN_4 = CURRENT_DATE) )

Опишем результат такого предиката. Если COLUMN_1 и COLUMN_2 будут равны, то вычисление останавливается, и предикат возвращает истину.

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

Если COLUMN_1 больше, то COLUMN_3 сравнивается с COLUMN_1. Если значение COLUMN_3 больше или равно COLUMN_1, то вычисление останавливается, и весь предикат вернет ложь.

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

Включающее ИЛИ в сравнении с исключающим

Оператор OR В Firebird является включающим ИЛИ (одно условие или все условия должны быть истинными). Исключающее или (которое дает истину, только когда ровно одно условие является истинным, а все остальные ложными) не поддерживается.

Предикат IS [NOT] NULL

IS NULL и его противоположность IS NOT NULL являются парой предикатов, которые не используют группирование. Поскольку NULL не является значением, эти операторы не являются операторами сравнения. Они проверяют утверждение, что объект в левой части имеет значение (IS NOT NULL) или не имеет значения (IS NULL).

Если значение имеется, то IS NOT NULL возвращает истину независимо от содержимого, размера или типа данных значения.

Новички в SQL иногда путают ограничение NOT NULL с предикатами is [NOT] NULL. Общая ошибка считать, что IS NULL и IS NOT NULL проверяют, был ли определен столбец с ограничением NOT NULL. Это не так. Они тестируют текущее содержимое столбца на наличие или отсутствие значения.

Предикат is [NOT] NULL может быть использован для проверки входных данных, помещаемых в столбцы таблиц базы данных, имеющих ограничения NOT NULL. Обычно эти предикаты применяются в триггерах BEFORE INSERT (до добавления).

Более подробную информацию о NULL см. В разд. «Рассмотрение NULL».

Предикаты существования

Последняя группа предикатов включает предикаты, которые используют подзапросы для передачи значений для различного вида утверждений в условиях поиска. Ключевые слова для этих предикатов ALL, ANY, EXISTS, IN, SINGULAR и SOME. Они называются предикатами существования, потому что все они используются в предикатах поиска, которые разными способами проверяют существование значения в левой части предиката в выходных результатах включенных запросов к другим таблицам.

Все эти предикаты- описанные в табл. 21.6- используют в том или ином виде подзапросы. Тема подзапросов подробно рассматривается в главе 22.

Таблица 21.6. Предикаты существования

Предикат	Назначение
ALL	Проверяет, является ли сравнение истинным для всех значений, возвращенных подзапросом
[NOT] EXISTS	Существует ли (или нет) по крайней мере одно значение в выходном результате подзапроса
[NOT] IN	Существует ли (или нет) по крайней мере одно значение в выходном результате подзапроса
[NOT] SINGULAR	Проверяет, возвращает ли подзапрос в точности одно значение. Если возвращается NULL или более одного значения, то SINGULAR дает ложь (a NOT SINGULAR- истину)
SOME	Проверяет, является ли сравнение истинным по крайней мере для одного значения, возвращаемого подзапросом
ANY	Проверяет, является ли сравнение истинным по крайней мере для одного значения, возвращаемого подзапросом, SOME и ANY эквивалентны

Предикат EXISTS

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

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

! ! !

ВНИМАНИЕ! Счетчик строк, полученный в контексте одной транзакции для проверки условия последующей работы в другой транзакции, — например, для вычисления значения «следующего» ключа — является совершенно ненадежным.

. ! .

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

В первом примере EXISTS проверяет условия для выполнения изменения в операторе динамического SQL:

UPDATE TABLEA

SET COL6 =’SOLD’

WHERE COL1 =99

AND EXISTS(SELECT COLB FROM TABLEB WHERE COLB = 99);

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

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

UPDATE TABLEA

SET TABLEA.COL6 =’SOLD’

WHERE EXISTS(SELECT TABLEB.COLB FROM TABLEB

WHERE TABLEB.COLB = TABLEA.COL1) ;

Действием такого выражения существования будет: «Если в таблице TABLEB существует хотя бы одна соответствующая строка, то выполнить изменение».

Предикат IN

Предикат IN, используемый в подзапросе, похож на EXISTS постольку, поскольку он может проверять результат подзапроса. Например:

UPDATE TABLEA

SET COL6 =’SOLD’

WHERE COL1 IN (SELECT COLB FROM TABLEB

WHERE COL1 > 0);

В этом случае подзапрос возвращает набор всех значений столбца COLB второй таблицы, которые соответствуют его собственному предложению WHERE. Предикат IN приводит к сравнению COL1 С каждым возвращенным значением набора, пока не будет найдено соответствие. Он будет выполнять изменение каждой строки таблицы TABLEA, для которой значение COL1 соответствует значению в наборе.

! ! !

ПРИМЕЧАНИЕ. В Firebird предикат IN, который использует набор подзапроса, фактически реализуется предикатом EXISTS для операции сравнения.

. ! .

Ограничения

С точки зрения производительности предикат IN не будет полезен, когда подзапрос возвращает достаточно большое количество значений. Чаще он используется при формировании набора значений для сравнения из небольшой таблицы соответствия (lookup table) или из фиксированного набора констант, например:

UPDATE TABLEA SET C0L6 =’SOLD’

WHERE COL1 IN (‘А’, ‘В’, ‘C’, ‘D’);

Количество констант в наборе имеет ограничение максимум 1500 значений- возможно меньше, если значения велики по размеру, и размер строки запроса превышает его лимит в 64 Кбайт.

Предикат ALL

Его использование лучше проиллюстрировать, начав с примера:

SELECT * FROM MEMBERSHIP

WHERE

(EXTRACT (YEAR FROM CURRENT_DATE) — EXTRACT(YEAR FROM DATE_OF_BIRTH))

< ALL (SELECT MINIMUM_AGE FROM AGE_GROUP) ;

Выражение в левой части вычисляет возраст в годах для каждого человека из таблицы MEMBERSHIP и выводит только тех людей, кто моложе минимального возраста в таблице MINIMUM AGE. Предикат ALL имеет ограниченное использование, поскольку он подходит только для поиска в случае сортировки от большего к меньшему при проверке исключения.

Предикат SINGULAR

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

SELECT OH.ORDER_ID FROM ORDER_HEADER OH

WHERE OH.ORDER_ID = SINGULAR(SELECT OD.ORDER_ID

FROM ORDER_DETAIL OD) ;

Предикаты ANY и SOME

Эти два предиката идентичны по поведению. Очевидно, оба представлены в стандарте SQL для взаимозаменяемого использования с целью улучшения читаемости операторов. При сравнении на равенство они логически эквивалентны предикату EXISTS. При этом, поскольку они предназначены и для других сравнений, таких как >, <, >=, <=, STARTING WITH, LIKE и CONTAINING, они в особенности полезны для проверок существования, где EXISTS не может быть использован.

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

SELECT E.EMP_NO, E.FULL_NAME, E.HIRE_DATE

FROM EMPLOYEE E

WHERE E.HIRE_DATE + 365 > SOME (

SELECT SH.CHANGE_DATE FROM SALARY_HISTORY SH

WHERE SH.EMP_NO = E.EMP_NO);

Алиасы таблиц

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

Обсуждение NULL

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

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

NULL в выражениях

NULL не является значением, следовательно, он не может быть «равным» какому-либо значению. Например, воз такой предикат

WHERE (COL1 = NULL)

вернет ошибку, потому что оператор равенства не является действительным для NULL, NULL является состоянием, и правильным предикатом проверки на NULL будет IS NULL. Скорректированный предикат для предыдущего ошибочного тестирования будет иметь вид:

WHERE (COL1 IS NULL)

Вы также можете выполнять проверку на непустое значение:

WHERE (COL1 IS NOT NULL)

Два NULL не равны один другому. При конструировании выражений помните о тех случаях, когда предикат будет сведен к виду:

WHERE <NULL result> = <NULL result>

Здесь результатом всегда будет ложь при сравнении двух NULL. Выражение типа

WHERE COL1 > NULL

будет ошибочным, потому что арифметический оператор недопустим для NULL.

NULL в вычислениях

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

UPDATE TABLEA

SET COL4 = COL4 + C0L5;

присвоит столбцу COL4 значение NULL, если значением COL5 является NULL.

В агрегатном (обобщающем) выражении, использующем операторы типа SUMO, AVG() или COUNT (<ИМЯ столбца>), строки, содержащие NULL В соответствующем столбце, будут проигнорированы, AVG() сформирует числитель, суммируя непустые значения, и знаменатель, подсчитывая строки, содержащие непустые значения.

Понимание истинности и ложности

Семантически, если предикат возвращает «неопределенность», это не является ни истиной, ни ложью. В SQL при этом утверждения разрешаются только в виде «истина» или «ложь» — утверждение, которое не вычисляется как «истина», рассматривается как «ложь».

Условие IF, неявно присутствующее в предикатах поиска, может вызвать у вас галлюцинацию, когда NOT используется во вложенном условии:

NOT <условие, дающее ложь> дает TRUE

в то время как

NOT <условие, дающее NULL> дает NULL

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

WHERE

NOT (COLUMNA = COLUMNB)

Если оба столбца COLUMNA и COLUMNB имеют значения и не равны, вычисление внутреннего предиката (того, что заключен в скобки) даст «ложь». Утверждение NOT (FALSE) вернет истину — противоположность ложного значения.

Однако если любой из столбцов является NULL, внутренний предикат даст NULL, имеющий семантическое значение «неопределенный» («непроверенный», «неопознаваемый»). Окончательное утверждение будет NOT (NULL), а результатом станет NULL. Обратите также внимание, что NOT (NULL) не является тем же самым, что и IS NOT NULL- чисто бинарный предикат, который никогда не вернет «неопределенное значение».

! ! !

ВНИМАНИЕ! Этот урок заключается в том, что нужно быть внимательным при работе с логикой SQL и всегда жестко проверять ваши выражения. Учитывайте условия NULL, если вы можете это сделать, полностью исключайте утверждения NOT во вложенных предикатах.

. ! .

NULL и внешние функции (UDF)

NULL не может передавать в виде входа или выхода функции в большинстве библиотек внешних функций, потому что они следуют соглашению InterBase о передаче аргументов по ссылке или по значению. Большинство доступных библиотек UDF используют это соглашение InterBase.

Сервер Firebird способен передавать аргументы в UDF по дескриптору. Это механизм, который стандартизует аргументы типов данных Firebird, делая возможным передачу NULL в качестве аргумента кода включающего языка, хотя и не предоставляя возможности получать NULL В качестве возвращаемого значения. Функции в библиотеке fbudf (в каталоге /UDF инсталляции сервера) используют дескрипторы.

Установка значения в NULL

Элемент данных может быть сделан NULL только в столбце, для которого не указано ограничение NOT NULL (СМ. разд. «Ограничение NOT NULL» главы 16).

В операторе UPDATE символом назначения является «=»:

UPDATE FOO SET COL3 = NULL

WHERE COL2 = 4;

В операторе INSERT передавайте ключевое слово NULL на месте значения:

INSERT INTO FOO (COL1, COL2, COL3)

VALUES (1, 2, NULL);

для столбца.

! ! !

ПРИМЕЧАНИЕ. В этом случае NULL перекрывает любое значение по умолчанию

. ! .

Другой способ помещения NULL С помощью оператора INSERT — опустить имя столбца, допускающего пустое значение, во входном списке. Например, следующий оператор будет иметь тот же эффект, что и предыдущий, если значение по умолчанию не определено для столбца COL3:

INSERT INTO FOO (COL1, COL2)

VALUES (1, 2);

В PSQL (языке хранимых процедур) используйте символ «=» в качестве оператора присваивания при назначении переменной NULL, используйте is [NOT] NULL в предикате проверки IF:

. . .

DECLARE VARIABLE foobar integer;

. . .

IF (COL1 IS NOT NULL) THEN

FOOBAR = NULL;

Использование выражений

Вычисляемые столбцы

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

Поля, создаваемые в операторах

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

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

Алиасы получаемых полей и столбцов

Выражения, вывод подзапросов и константы могут быть использованы в Firebird для передачи получаемых, или «искусственных» полей, в выходные наборы. Для предоставления возможности назначать имена во время выполнения Firebird поддерживает стандарт SQL назначения алиасов столбцам, что позволяет выводить любые столбцы с алиасами из одного или более символов.

Например, следующий оператор

SELECT COL_ID, COLA || ‘,’ ||COLB AS comput col

FROM TABLEA;

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

! ! !

ВНИМАНИЕ! Когда два столбца соединяются подобным образом в любом выражении, выходное поле будет NULL, если любой из столбцов является NULL. Это также является стандартным поведением SQL.

. ! .

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

SELECT COL_ID,

COLA,

COLB,

(SELECT SOMECOL FROM TABLEB

WHERE UNIQUE_ID = ’99’) AS B_SOMECOL

FROM TABLEA

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

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

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

SELECT CAST(CURRENT_DATE as VARCHAR(10)) || ‘-‘ || REGISTRATION

FROM AIRCRAFT;

генерирует такой вывод:

<пробельная титульная строка>

===============

2003- 01-01-GORILLA

2004- 02-28-KANGAROO

. . .

Одни рассматривают это как ошибку, другие — как особенность. Для администратора базы данных удобнее быстро создать запрос, не беспокоясь о деталях. Это строго не рекомендуется использовать как «особенность» в приложениях. Выходные столбцы без имени слишком часто приводят к ошибкам и двусмысленностям в клиентских интерфейсах. Те же самые сложности могут появиться в интерфейсах приложений, если вы используете один и тот же алиас более одного раза в одном выходе.

Константы и переменные в качестве вывода времени выполнения

Существует возможность «создавать» выходной столбец в операторе SELECT, используя выражение, в которое включены не столбцы, а константы или контекстные переменные и алиасы. В следующем тривиальном примере запрос добавляет к каждой строке столбец, содержащий константное значение ‘This is just a demo’:

SELECT

LAST_NAME,

FIRST_NAME,

‘This is just a demo’ AS DEMO_STRING

FROM MEMBERSHIP;

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

Использование контекстных переменных

Firebird имеет набор переменных, предоставляющих мгновенный снимок значений сервера. Как вы уже видели, многие из этих значений могут быть использованы в выражениях, выполняющих вычисления. Они также могут быть использованы в выражениях, сохраняющих их в столбцах базы данных, или в спецификациях COMPUTED BY (см. разд. «Объявление столбцов COMPUTED BY»).

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

SELECT

LOG_ID,

L0G_DATE,

. . .

CURRENT_DATE AS BASE_DATE,

СURRENT_TRANSACTION AS BASE_TRANSACTI0N,

. . .

FROM LOG

WHERE . . .

Подробный список доступных переменных и примеры их использования см. в разд. «Контекстные переменные» главы 8.

Выражения, использующие CASE() и дружественные функции

Firebird предоставляет из стандарта SQL-99 синтаксис выражения CASE и двух его «сокращенных» производных функций — COALESCE() и NULLIF(). Выражение CASE() может быть использовано для вывода константного значения, условно определенного во время выполнения в соответствии со значением указанного столбца в текущей строке запрашиваемой таблицы.

CASE()

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

Доступность

DSQL, PSQL, ISQL, ESQL, Firebird 1.5 и выше. Любая платформа.

Синтаксис

CASE {<значение 1> | <пустое-предложение>}

WHEN {{NULL | <значение 2>} | <предикат-поиска> }

THEN {<результат 1> | NULL }

WHEN…THEN {<результат 2> | NULL}

[WHEN…THEN {<результат N> | NULL}]

[ELSE {<результат (n + 1)> | NULL} ]

END [, ]

Дополнительные ключевые слова

WHEN. . .THEN являются ключевыми словами в каждом предложении условие/результат. Требуется, по меньшей мере, одно предложение условие/результат.

ELSE предшествует необязательному «последнему» результату, который возвращается, если не выполняется ни одно предыдущее предложение.

Аргументы

значение 1 является идентификатором столбца, значение которого вычисляется. Может быть опущен. В этом случае каждое предложение WHEN должно быть предикатом поиска, содержащим идентификатор этого столбца.

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

* Если идентификатор столбца (значение 1) указан в предложении CASE, то значение 2 остается одиночным в каждом предложении WHEN и будет сравниваться со значением 1.

* Если идентификатор столбца не указан в предложении CASE, то и значение 1, и значение 2 включаются в каждое предложение WHEN в качестве предиката поиска в форме (значение 1 = значение 2).

результат 1 — тот результат, который будет возвращен в случае, когда значение i будет соответствовать значению 2.

результат 2- тот результат, Который будет возвращен в случае, когда значение 1 будет соответствовать значению 3 и т.д.

Возвращаемое значение

Предложение CASE возвращает единственное значение. Если не выполняется ни одно условие и не указано предложение ELSE, то возвращаемый результат будет NULL.

Замечания

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

Использование единственного предложения условие/результат имеет смысл, только если присутствует предложение ELSE. Хотя это менее элегантно, чем использование соответствующих функций COALESCE() и NULLIF().

Примеры

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

одним и тем же набором предикатов.

Простой синтаксис:

SELECT

о.ID,

о.Description,

CASE о.Status

WHEN 1 THEN ‘confirmed’

WHEN 2 THEN ‘in production’

WHEN 3 THEN ‘ready’

WHEN 4 THEN ‘shipped’

ELSE ‘unknown status »’ || o.Status || »»

END

FROM Orders o;

Этот синтаксис использует предикаты поиска в предложении WHEN:

SELECT

о.ID,

о.Description,

CASE

WHEN (о.Status IS NULL) THEN ‘new’

WHEN (o.Status = 1) THEN ‘confirmed’

WHEN (o.Status = 3) THEN ‘in production’

WHEN (o.Status = 4) THEN ‘ready’

WHEN (o.Status = 5) THEN ‘shipped’

ELSE ‘unknown status »’ || o.Status || »»

END

FROM Orders o;

COALESCE()

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

Доступность

DSQL, PSQL, ISQL, ESQL, Firebird 1.5 и выше. Любая платформа.

Синтаксис

COALESCE (<значение 1> { , значение 2 [, … значение n]})

Аргументы

значение 1 — значение столбца или выражение, которое будет вычисляться. Если это не NULL, то оно будет возвращаемым значением.

значение 2 — значение столбца или выражение, которое будет вычисляться, если значение 1 будет NULL.

значение n — последнее значение или выражение, которое будет вычисляться, если предыдущие значения в списке будут NULL.

Возвращаемое значение

Возвращает первое не NULL значение из списка.

Замечания

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

В первом варианте (простого, двоичного) синтаксиса COALESCE (значение1, Значение2) логика вычисления эквивалентна:

CASE WHEN V1 IS NOT NULL THEN V1 ELSE V2 END

Если присутствуют три или более аргумента — COALESCE (значение1, значение2, … значениеN), — логика вычисления эквивалентна следующей:

CASE

WHEN V1 IS NOT NULL THEN V1

ELSE COALESCE (V2,…,Vn)

END

Последнее значение в списке должно быть задано, чтобы быть уверенным, что что-то будет возвращено.

Пример

В первом запросе если соединение не находит соответствия в таблице EMPLOYEE для TEAM_LEADER из таблицы PROJECT, то запрос вернет строку ‘ [Not assigned]’ (Не назначено) вместо NULL, которое в противном случае должно было вернуть внешнее соединение в качестве значения FULL NAME:

SELECT

PROJ_NAME AS Projectname,

COALESCE (e. FULL_NAME, ‘ [Not assigned]’) AS Employeename

FROM PROJECT p

LEFT JOIN EMPLOYEE e ON (e.EMP_NO = p. TEAM_LEADER) ;

В следующем запросе вычисление начинается с самой левой позиции в списке. Если присутствует значение PHONE, запрос проверяет, присутствует ли значение MOBILEPHONE, иначе он возвращает строку ‘unknown’ (Неопределенный):

SELECT

COALESCE(Phone, MobilePhone, ‘Unknown’) AS Phonenumber

FROM Relations

Связанные или похожие функции

Пользователи Firebird 1.0.x, смотрите внешние функции INVL() и SNVL().

NULLIF()

NULLIF() возвращает NULL в случае соответствия двух непустых значений, иначе он возвращает значение подвыражения.

Доступность

DSQL, PSQL, ISQL, ESQL, Firebird 1.5 и выше. Любая платформа.

Синтаксис

NULLIF (значение 1, значение 2)

Аргументы

значение 1 — столбец или вычисляемое выражение.

значение 2- константа или выражение, с которым сравнивается значение 1. Если они соответствуют, NULLIF возвращает NOLL.

Возвращаемое значение

Возвращаемое значение будет NULL, если значение 1 и значение 2 соответствуют друг другу. ЕСЛИ нет соответствия, возвращается значение 1.

Замечания

NULLIFO является сокращением для следующего выражения CASE: CASE WHEN(VALUE_1 = value_2) THEN NULL ELSE VALUE_1 END

Пример

Этот оператор устанавливает значение столбца STOCK из таблицы PRODUCTS в ULL для всех строк, где его текущее значение равно нулю:

UPDATE PRODUCTS

SET STOCK = NULLIF(STOCK, 0)

Связанные или похожие функции

Пользователи Firebird 1.0.x, смотрите INULLIF() и SNULLIF().

Определение столбцов COMPUTED BY

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

ALTER TABLE MEMBERSHIP

ADD FULL_NAME COMPUTED BY FIRST_NAME || ‘ ‘ || LAST_NAME;

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

Условия поиска

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

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

Предложения WHERE

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

Инверсия операндов

Упрощенный синтаксис предикатов в предложении WHERE имеет вид:

WHERE значение оператор значение

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

WHERE ACOL = значение

WHERE значение = ACOL

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

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

Например, множество предикатов в форме

<выражение-или-константа> = COLUMNX

делают работу по исправлению ошибок и пересмотру кода каторжным трудом по сравнению с

COLUMNX = <выражение-или-константа>

Важно принимать дополнительные «усилия», чтобы сделать все выражения совместимыми.

Массивы, BLOB и строки

Массивы вовсе не могут использоваться в предикатах поиска, поскольку SQL не имеет средств доступа к хранящимся в массивах данным. Выражения для столбцов BLOB являются весьма ограниченными, BLOB не может сравниваться на равенство ни с другим BLOB, ни с любым другим типом данных. Текстовый BLOB может использоваться в STARTING WITH и с некоторыми ограничениями в предикатах LIKE и CONTAINING. Некоторые внешние функции могут работать с типами BLOB — см. функции BLOB В приложении 1.

Строки могут проверяться любыми операторами сравнения, хотя такие операторы, как <, >, >= и <=, не часто являются полезными.

Условия упорядочения и группирования

Когда выходное поле создается в выражении, оно может быть использовано для установления условий упорядочения или группирования набора. При этом синтаксис правил для выражений в ORDER BY и GROUP BY различается, также существуют различия между версиями 1.0.x и 1.5.

Выражения для ORDER BY

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

SELECT

MEMBER_ID,

LAST_NAME || ‘, ‘ || FIRST_NAME AS FULL_NAME,

JOIN_DATE

FROM MEMBERSHIP

ORDER BY 2;

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

В версии 1.5 и более поздних в наборах, отличных от UNION, условие упорядочения может быть выражением, возвращающим значение, которое может оказаться осмысленным для упорядочения. Например, предложение ORDER BY В следующем операторе вызывает функцию, которая возвращает длину столбца описания и использует ее для упорядочения выходного набора от большего к меньшему:

SELECT DOCUMENTED, TITLE, DESCRIPTION FROM DOCUMENT

ORDER BY STRLEN(DESCRIPTION) DESC;

Выражения для GROUP BY

В SQL оператор GROUP BY используется для собирания наборов данных и иерархической их организации или суммирования.

Во всех версиях Firebird вы можете выполнять иерархическое группирование, основанное на вызове внешней функции (UDF), однако в версии 1.0.x вы не можете использовать порядковый номер выходного столбца в качестве условия группирования. Firebird 1.5 добавляет возможность использования в GROUP BY порядкового номера, а также несколько других типов выражений, включая выражения подзапросов.

Другие изменения в Firebird 1.5 ужесточают отдельные правила группирования, убирая поддержку некоторых неправильных вариантов синтаксиса группирования, которые были допустимы в Firebird 1.0.x.

Правила и взаимодействия выражений для группирования и упорядочения иногда являются сложными в реализации. Эти темы подробно обсуждаются в главе 23.

Следующий пример для версии 1.5 запрашивает в таблице MEMBERSHIP и выводит статистику, показывающую количество участников, объединенных в каждом месяце:

SELECT

MEMBER_TYPE,

EXTRACT(MONTH FROM J0IN_DATE) AS MONTH_NUMBER,

/* 1, 2, и т.д. */

F_CMONTHLONG(JOIN_DATE) AS SMONTH,

/* UDF, возвращающая месяц в виде строки */

COUNT (*) AS MEMBERS_JOINED

FROM MEMBERSHIP

GROUP BY

MEMBER_TYPE, EXTRACT(MONTH FROM JOIN_DATE);

Выражения CHECK в DDL

Применение выражений не ограничивается только DML; мы уже видели их использование в определении таблицы для описания вычисляемых столбцов. Каждый раз, когда вы определяете ограничение CHECK для таблицы, столбца или домена, вы применяете выражения. По своей природе ограничение CHECK выполняет проверку на одно или более значений — тестирует предикат. Вот пример, где проверяется номер сотового телефона участника, который должен начинаться с нуля, если номер вообще присутствует:

ALTER TABLE MEMBERSHIP

ADD CONSTRAINT CHECK_CELLPHONE _NO

CHECK (CELLPHONE_NO IS NULL OR CELLPHONE_NO STARTING WITH ‘0’);

Выражения в PSQL

Процедурный язык для триггеров и хранимых процедур PSQL широко использует выражения для управления потоком выполнения. PSQL предоставляет структуры IF(<предикат>) THEN и WHILE(<предикат>) DO. Любой предикат, который может быть использован в условии поиска, также может быть предикатом для условия управления потоком в программе.

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

CREATE TRIGGER BI_MEMBERSHIP FOR MEMBERSHIP

ACTIVE BEFORE INSERT POSITION 0

BEGIN

IF (NEW.MEMBER_ID IS NULL) THEN

NEW. MEMBER_I D — GEN_ID(GEN_MEMBER_ID, 1);

END

Подробную информацию о написании триггеров и хранимых процедур см. в части VII.

Вызовы функций

После установки Firebird содержит минимальный набор внутренних функций SQL. Хотя новые функции появляются время от времени, тем не менее сохраняется одно из основных достоинств Firebird: малый объем памяти, занимаемый сервером.

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

Внутренние функции SQL

В табл. 21.7 представлены внутренние функции SQL, доступные в Firebird.

Таблица 21.7. Внутренне реализованные функции SQL

Функция	Тип	Назначение
CAST()	Преобразование	Преобразует столбец из одного типа данных в другой
EXTRACT()	Преобразование	Выделяет части даты и времени (год, месяц, день и т.д.) из значений DATE, TIME и TIMESTAMP
SUBSTRING()	Строка	Отыскивает последовательность символов в строке
UPPER()	Строка	Преобразует символы в строке в верхний регистр
GEN_ID()	Генерация	Возвращает значение генератора
AVGO	Агрегат	Вычисляет среднее значение набора значений
COUNT()	Агрегат	Возвращает количество строк, которые удовлетворяют условию поиска запроса
MAX()	Агрегат	Отыскивает максимальное значение в наборе значений
MIN()	Агрегат	Отыскивает минимальное значение в наборе значений
SUM()	Агрегат	Суммирует значения в наборе числовых значений

Функции преобразования

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

CAST()

Функция CAST() широко используется. Она позволяет преобразовывать элемент данных одного типа данных в другой тип или трактовать его как другой тип данных.

Доступность

DSQL, PSQL, ISQL, ESQL, Firebird 1.5 и выше. Любая платформа.

Синтаксис

CAST(значение AS <тип-данных>)

Дополнительные ключевые слова

Фраза AS <тип-данных> с аргументом является обязательной.

Аргументы

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

<тип-данных> должен быть родным типом данных Firebird. Нельзя указывать имя домена. Рис. 8.1 показывает все допустимые преобразования из одного типа в другой.

Возвращаемое значение

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

Пример

В следующем фрагменте PSQL поле LOG_DATE типа данных TIMESTAMP преобразуется в тип данных DATE, потому что для вычисления нужно получить целые дни:

. . .

IF (CURRENT_DATE — CAST (LOG_DATE AS DATE) = 30) THEN

STATUS = ’30 DAYS’;

Следующий оператор выбирает значение из столбца типа INTEGER, преобразует его в строку и соединяет со столбцом типа CHAR(3) для формирования значения другого столбца:

UPDATE MEMBERSHIP

SET MEMBER_CODE = MEMBER_GROUP || CAST(MEMBER_ID AS CHAR(8))

WHERE MEMBER_CODE IS NULL;

Связанные материалы

См. главу 8, где более подробно осуждается функция CAST(), а также последующие главы, в которых индивидуально рассматриваются типы данных.

EXTRACT()

Эта функция выделяет часть полей типа данных DATE, TIME и TIMESTAMP в виде числа.

Доступность

DSQL, PSQL, ISQL, ESQL, Firebird 1.5 и выше. Любая платформа.

Синтаксис

EXTRACT(часть FROM поле)

Необязательные ключевые слова

Аргументы

часть является одним значением из указанного списка необязательных ключевых слов, WEEKDAY выделяет день недели (воскресенье = 1, понедельник = 2 и т.д.), YEARDAY выделяет день в году (от 1 января = 1 до 366).

поле- поле типа данных DATE, TIME или TIMESTAMP (столбец, переменная или выражение).

Возвращаемое значение

Все части возвращают SMALLINT за исключением SECOND, которое возвращает

DECIMAL(6,4).

Замечания

EXTRACT будет работать только со значениями, которые преобразуются к полям дата/время.

Пример

Следующий оператор возвращает имена и дни рождения, упорядоченные no BIRTHDAY, для всех участников, имеющих день рождения в текущем месяце:

SELECT

FIRST_NAME,

LAST_NAME,

EXTRACT(DAY FROM DATE_OF_BIRTH) AS BIRTHDAY

FROM MEMBERSHIP

WHERE DATE_OF_BIRTH IS NOT NULL

AND EXTRACT (MONTH FROM DATE_OF_BIRTH) = EXTRACT (MONTH FROM

CURRENT_DATE)

ORDER BY 3;

Строковые функции

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

SUBSTRING()

SUBSTRING() является внутренней функцией, реализующей функцию ANSI SQL SUBSTRING(). Она возвращает поток, состоящий из байта с номером начальная-позиция и всех последующих байтов до конца строки значение. Если указано необязательное предложение FOR длина, она вернет меньшее из длина байт и количество байт до конца входного потока.

Доступность

DSQL, PSQL, ISQL, ESQL, Firebird 1.5 и выше. Любая платформа.

Синтаксис

SUBSTRING(значение FROM начальная-позиция [FOR длина])

Необязательные ключевые слова

Необязательное предложение FOR задает длину возвращаемой подстроки.

Аргументы

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

начальная-позиция должна преобразовываться в целое >= 1. Не может быть заменяемым параметром.

длина должна преобразовываться в целое >= 1. Не может быть заменяемым параметром.

Возвращаемое значение

Возвращаемое значение является строкой.

Замечания

Значения начальная-позиция и длина являются позициями байтов, что имеет значение для многобайтовых наборов символов.

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

Для аргументов столбцов BLOB указанный столбец должен быть двоичным BLOB (SUB_TYPE 0) или текстовым BLOB (SUB_TYPE 1) с набором символов один байт на символ. В настоящий момент функция не обрабатывает текстовые BLOB с наборами символов Chinese (максимум два байта на символ) и Unicode (максимум три байта на символ).

Пример

Следующий оператор будет изменять значение столбца COLUMNB, присваивая ему строку до 99 символов, начиная с четвертой позиции оригинальной строки:

UPDATE ATABLE

SET COLUMNB = SUBSTRING (COLUMNB FROM 4 FOR 99)

WHERE …

Связанные или похожие функции

См. также внешние функции SUBSTR(), SUBSTRLEN() и RTRIM().

UPPER()

Преобразует все символы строки в верхний регистр.

Доступность

DSQL, PSQL, ISQL, ESQL; обеспечивает работу со строками в тех наборах символов и последовательностях сортировки, которые поддерживают преобразование нижний/верхний регистры. Любая платформа.

Синтаксис

UPPER(значение)

Аргументы

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

Возвращаемое значение

Если набор символов и последовательность сортировки поддерживают преобразование в верхний регистр, функция возвращает строку, в которой все символы преобразованы в верхний регистр. Строка имеет ту же длину, что и входное значение. Для наборов символов, не поддерживающих преобразование в верхний регистр, функция возвращает неизмененное входное значение,^[76]

Замечания

Входное значение не может иметь тип данных BLOB.

Пример

Следующее ограничение CHECK проверяет входную строку, выясняя, содержит ли она все символы в верхнем регистре:

ALTER TABLE MEMBERSHIP

ADD CONSTRAINT CHECK_LOCALITY_CASE

CHECK(LOCALITY = UPPER(LOCALITY));

Связанные или похожие функции

См. также внешние функции LOWER() и F_PROPERCASE().

Функция для получения значения генератора

Функция GEN_ID() является механизмом, с помощью которого модули PSQL и приложения получают числа от генераторов. Генераторы подробно обсуждаются в главе 9. См. также разд. «Реализация автоинкрементных ключей» главы 31.

GEN_ID()

GEN_IDO вычисляет и возвращает значение генератора.

Доступность

DSQL, PSQL, ISQL, ESQL, Firebird 1.5 и выше. Любая платформа. Синтаксис

GEN_ID(значение1, значение2)

Аргументы

значение1 является идентификатором существующего генератора.

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

Возвращаемое значение

Возвращается значение типа BIGINT.

Замечания

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

GEN_IDO всегда выполняется вне контекста какой-либо транзакции. Эта операция в Firebird доступна только пользователю. Как только число будет получено от генератора, оно никогда не будет создано тем же генератором, за исключением случаев, когда пользователь изменит последовательность, используя отрицательную величину шага, или с помощью оператора SET GENERATOR.

Пример

Следующий оператор возвращает новое значение генератора GEN_SERIAL:

SELECT GEN_ID(GEN_SERIAL, 1) FROM RDB$DATABASE;

В приведенном далее примере генератор используется в триггере BEFORE INSERT для получения значения первичного ключа:

CREATE TRIGGER BI_AUTHORS FOR AUTHORS

ACTIVE BEFORE INSERT POSITION 0

BEGIN

IF (NEW.AUTHOR_ID IS NULL) THEN

NEW.AUTHOR_ID = GEN_ID(GEN_AUTHOR_ID, 1);

END ^

Агрегатные функции

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

Firebird имеет группу агрегатных функций, которые чаще всего используются в комбинации с условиями группирования для вычисления итогов или статистики на уровне группы. Агрегатными функциями являются: SUM(), вычисляющая итог, MAX() и MIN(), возвращающие наибольшее и наименьшее значение соответственно, и AVG(), вычисляющая среднее значение. Функция COUNT() также ведет себя как агрегатная функция в сгруппированных запросах.

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

«Негруппированные» объединения

В небольшом количестве случаев агрегатные функции могут оперировать с наборами, которые не являются субъектами предложения GROUP BY и возвращающими не более одной строки. Логически результат подобного запроса не может выводить значения любого столбца базы данных или значения, полученные от неагрегатных функций. Для иллюстрации рассмотрим следующий запрос, который объединяет бюджеты одного проекта за один фискальный год. Таблица имеет одну запись бюджета для каждого из пяти отделов:

SELECT

‘MKTPR-1994’ AS PROJECT,

SUM(PROJECTED_BUDGET) AS TOTAL_BUDGET

FROM PROJ_DEPT_BUDGET

WHERE PROJ_ID = ‘MKTPR’ AND FISCAL_YEAR = 1994;

Выходом будет одна строка: строковое поле времени выполнения и вычисленный итог.

Внешние функции (UDF)

Внешние функции являются вспомогательными программами, написанными на языке программирования, таком как С, C++ или Pascal, и скомпилированными как совместно используемые двоичные библиотеки- DLL в Windows или совместно используемые объекты для других платформ, которые поддерживают динамическую загрузку. Как и стандартные встроенные функции SQL, внешние функции могут быть разработаны для выполнения преобразований или вычислений, реализация которых либо слишком сложна, либо вовсе невозможна средствами языка SQL.

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

Фрагмент «определенные пользователем» в названии функций означает, что вы можете писать свои собственные функции. Возможности создания пользовательских функций для вашего сервера Firebird ограничиваются лишь вашей изобретательностью и умением программировать на включающем языке. Допустимо включение статистических, строковых, математических функций, функций даты, подпрограмм форматирования данных и даже пользовательского процессора для выполнения регулярных выражений (regular expression, regexes).

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

Существующие библиотеки

Firebird поставляется с двумя предварительно встроенными библиотеками внешних функций. Библиотеки совместно используемых объектов размещаются по умолчанию в каталоге /UDF корневого каталога Firebird. Расширения файлов:

* dll — для Windows;

* so — для других поддерживаемых платформ.

Библиотека ib udf- библиотека полезных базовых функций- наследуется Firebird от своего предшественника InterBase. Она нужна для вызова некоторых утилит управления памятью, которые находятся в совместно используемом объекте с именем ib utii, размещенном в каталоге /bin. Эта библиотека передает параметры по значению или по ссылке в согласованном стиле InterBase. В некоторых подпрограммах исправлены ошибки для Firebird, так что не используйте версии, поставляемые с продуктами Borland.

Библиотеку fbudf создал Клавдио Валдеррама (Claudio Valderrama). Она передает параметры через дескрипторы Firebird, что является наиболее надежным способом гарантировать отсутствие внутренних ошибок в результате выделения памяти и преобразования типов.

Свободно доступными также являются некоторые библиотеки UDF, включая библиотеку FreeUDFLib, вначале написанную Грегори Диц (Gregory Deatz) для Borland Delphi. Библиотека FreeUDFLib содержит большое количество функций для строк, математических операций, типов данных BLOB и даты. Она поддерживалась, корректировалась и дополнялась разными людьми в течение многих лет. Будьте внимательны при получении версии этой библиотеки, которая правильно работает в диалекте 3 с типами данных даты и времени. Такая версия для Windows доступна на http://www.ibase.ru. Исходный код на С для версии POSIX доступен как FreeUDFLibC, однако на момент написания этой главы не было надежного бинарного кода, доступного для загрузки.

Конфигурация и вопросы безопасности

Коды внешних модулей являются по своей сути уязвимыми для злоумышленников и небрежных администраторов. Как-никак это просто файлы файловой системы.

В Firebird 1.0.x вы можете- и должны- явно сконфигурировать положение библиотек внешних функций на сервере, используя параметр externai_function_directory в файле конфигурации (isc config для серверов POSIX и ibconfig для Windows). Это следует сделать администратору базы данных для обеспечения того, что библиотеки не будут перезаписаны — случайно или неавторизованными посетителями.

В Firebird 1.5 и выше доступ к внешним файлам разного вида может быть ограничен на различных уровнях доступа. По умолчанию, если вы решите разместить библиотеки внешних функций в каталогах не по умолчанию, они будут недоступны для сервера. Просмотрите замечания в главе 36 относительно конфигурирования параметра uDFAccess в файле firebird.conf для разрешения подобных проблем.

Устойчивость

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

Объявление функции для базы данных

Когда UDF написана, скомпилирована, тщательно протестирована и инсталлирована в соответствующий каталог на сервере, она должна быть объявлена для базы данных, чтобы ее можно было использовать как функцию SQL. Для этого используйте оператор DDL DECLARE EXTERNAL FUNCTION. Вы можете объявить функции с использованием isql, любого другого интерактивного инструмента SQL или скрипта.

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

Объявление функции для базы данных информирует эту базу данных относительно:

* имени, с которым функция будет использована в операторах SQL. В объявлении вы можете использовать свое собственное имя- см. следующие замечания по синтаксису;

* количества аргументов и их типов данных;

* типа данных возвращаемого значения;

* имени (ENTRY_POINT), С которым функция существует в библиотеке;

* имени библиотеки (MODULE_NAME), которая содержит функцию; Синтаксис декларации:

DECLARE EXTERNAL FUNCTION имя [тип-данных | CSTRING (целое)

[, тип-данных | CSTRING (целое) …]]

RETURNS {тип-данных [BY VALUE] | CSTRING (целое)} [FREE_IT]

[RETURNS PARAMETER n]

ENTRY_POINT ‘точка-входа’

MODULE_NAME ‘имя -модуля’;

Табл. 21.8 подробно описывает аргументы.

Таблица 21.8. Аргументы оператора DECLARE EXTERNAL FUNCTION

Аргумент	Описание
имя	Имя UDF для использования в операторах SQL. Может отличаться от имени, указанного после ключевого слова ENTRY POINT. Если вы используете существующую библиотеку, то хорошо бы изменить предоставляемое имя — хотя бы для того, чтобы устранить путаницу при объявлении той же функции с другими именами в других базах данных
тип-данных	Тип данных для входного или возвращаемого параметра. Если аргументы не передаются по дескриптору, это тип данных включающего языка. Все входные параметры передаются в UDF по ссылке или по дескриптору. Возвращаемые параметры могут передаваться по ссылке, по значению или по дескриптору. Тип данных не может быть массивом или элементом массива
RETURNS	Спецификация возвращаемого значения функции
BY VALUE	Указывает, что возвращаемое значение должно передаваться по значению, а не по ссылке
CSTRING( целое)	Указывает, что UDF возвращает значение в виде строки с нулевым терминатором с максимальной длиной целое байтов
FREE_IT	Освобождает память возвращаемого значения после завершения выполнения UDF. Используйте это, только если память в UDF выделяется динамически с использованием функции ib_util_malloc, определенной в библиотеке ib_util. Библиотека ib_util должна находиться в каталоге /bin, чтобы вариант FKEE_IT мог работать
RETURNS PARAMETER n	Указывает, что функция возвращает n-й входной параметр. Это требуется для возвращения типов данных BLOB
точка-входа	Заключенная в апострофы строка, задающая имя, под которым UDF присутствует в исходном коде и сохранена в библиотеке UDF
имя-модуля	Заключенная в апострофы спецификация файла, идентифицирующая библиотеку, которая содержит UDF

Скрипты библиотеки внешних функций

Большинство библиотек внешних функций поставляется вместе с их собственными скриптами DDL, содержащими объявления для каждой функции и, обычно, некоторую краткую документацию. Существует соглашение именовать скрипт так же, как и библиотеку, но с использованием расширения файла SQL или sql. Однако не все общедоступные библиотеки придерживаются этого соглашения.

Скрипты ib udf.sql и fbudf.sql находятся в каталоге /UDF вашего каталога инсталляции сервера. Комплект FreeUDFLib содержит скрипт с именем extfuncs.sql. Вы можете свободно копировать и вставлять объявления для компоновки вашей собственной библиотеки из любимых объявлений.

Следующее объявление является примером из скрипта ib udf.sql:

DECLARE EXTERNAL FUNCTION ipad

CSTRING(80), INTEGER, CSTRING(1)

RETURNS CSTRING(80) FREE_IT

ENTRY_POINT ‘IB_UDF_lpad’ MODULE_NAME ‘ib_udf’;

Следующее объявление содержится в fbudf, оно передает аргументы по дескриптору в некоторые функции:

DECLARE EXTERNAL FUNCTION sright

VARCHAR(100) BY DESCRIPTOR, SMALLINT,

VARCHAR(100) RETURNS PARAMETER 3

ENTRY POINT ‘right’ MODULE_NAME ‘fbudf’;

Идентификатор (имя) функции

При объявлении внешней функции для базы данных вы не ограничены использованием только имен, появляющихся в скрипте. Имя функции должно быть уникальным среди имен всех функций, объявленных в базе данных. Библиотеки общего использования обычно соответствуют соглашению о поставляемых объявлениях, по которому эти имена «не наступают на ноги» идентификаторам, обычно используемым в другой библиотеке, поэтому вы можете увидеть некоторые странности в именах в этих скриптах.

Иногда вам может понадобиться объявить одну и ту же функцию для вашей базы данных более одного раза. Пока вы используете различные имена в EXTERNAL FUNCTION, вы можете объявлять функцию, имеющую те же ENTRY_POINT и MODULE_NAME, столько раз, сколько вам нужно.

! ! !

ВНИМАНИЕ! Никогда не изменяйте аргумент ENTRY_POINT. Аргумент MODULE_NAME не должен изменяться за исключением случая, когда необходимо использовать полный путь к библиотеке (см. разд. «Пути в объявлениях функций»).

. ! .

Размеры строковых аргументов

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

Если вам нужен аргумент для строковой функции, имеющий размер больший, чем значение по умолчанию, объявите аргумент в соответствии с вашими требованиями, убедитесь, что входные и выходные данные согласованы друг с другом и ни один аргумент не превышает максимального для VARCHAR значения 32 765 байт — заметьте: байтов, а не символов.

В следующем примере функция, описанная в скрипте fbudf.sql как sright, объявляется с именем srirgt2000, а размер параметров изменяется до 200 байт:

DECLARE EXTERNAL FUNCTION sright200

VARCHAR(200) BY DESCRIPTOR, SMALLINT,

VARCHAR (200) RETURNS PARAMETER 3

ENTRY_POINT ‘right’ MODULE_NAME ‘ fbudf’ ;

Пути в объявлениях функций

Для любой платформы в ссылке на модуль может отсутствовать путь или расширение файла. Это желательно, если вы собираетесь перемещать базу данных, содержащую объявления функций, на множество операционных систем. Конфигурация по умолчанию для Firebird 1.5 позволяет это сделать.

В версии 1.0.x нужно будет Сконфигурировать параметр external_function_directory в iscconfig/ibconfig для каждой платформы, на которой эти функции будут использоваться, поскольку эта версия не содержит «пути по умолчанию» для модулей функций. По умолчанию должен работать каталог /UDF, однако практика показывает, что это ненадежно без явно заданной конфигурации.

Для Firebird 1.5 и выше существуют другие режимы конфигурации (UDFAccess) для размещения библиотек функций (см. главу 36), включая RESTRICT, который позволяет задать для них один или более каталогов. Если вы используете RESTRICT, то в объявление нужно включить полный путь к модулю и расширение файла. В этом случае база данных не будет переносима на другую операционную систему, пока вы не удалите из базы данных функции и их зависимости.

Следующий пример показывает объявление функции с указанием полного пути:

DECLARE EXTERNAL FUNCTION lpad

CSTRING(80) , INTEGER, CSTRING(1)

RETURNS CSTRING(80) FREE_IT

ENTRY_POINT ‘ IB_UDF_lpad’ MODULE_NAME ‘/opt/extlibs/ib_udf .so’ ;

Список внешних функций

Приложение 1 содержит детальное описание с примерами внешних функций из библиотек ib_udf и fbudf из каталога /UDF каталога инсталляции Firebird, а также многие функции из FreeUDFLib.

Пора дальше

Важность использования логики выражений для трансформации абстрактных данных в осмысленную информацию аналогична важности использования средств SQL по слиянию данных из множества таблиц в один набор связанных данных. В следующей главе мы рассмотрим существующие в DML способы выполнения таких многотабличных операций. Эта глава заканчивается специальной темой оптимизации запросов Firebird и использованием планов запросов (предложение PLAN) В запросах SELECT.

ГЛАВА 22. Запросы к множеству таблиц.

Динамический SQL Firebird поддерживает три варианта запросов к множеству таблиц с помощью одного оператора SQL: соединения (joins), подзапросы (subqueries) и объединения (unions). Результат соединений, столбцов подзапроса и объединений является по своей природе набором данных только для чтения.

Firebird не поддерживает многотабличные запросы, которые находятся в нескольких базах данных. Тем не менее возможен запрос к нескольким таблицам одновременно из нескольких баз данных внутри одной транзакции, имеющей полное двухфазное завершение (two-phase commit- 2РС). Клиентские приложения могут сопоставлять данные и выполнять отдельные операторы манипулирования данными в пределах базы данных. Мультибазовые транзакции обсуждаются в части VI.

В этой главе мы рассмотрим три метода динамического поиска данных в нескольких таблицах^[77] в контексте одного оператора и одной базы данных: соединения, подзапросы и объединения.

Данная глава завершается темой оптимизации, где рассматриваются планы выполнения запросов, и как оптимизатор Firebird выбирает и использует индексы для создания этих планов. Понимание того, как оптимизатор «думает», может быть полезным при проектировании хорошо сформированных индексов и создании операторов запросов.

Виды многотабличных запросов

Три метода поиска данных во множестве таблиц довольно сильно отличаются друг от друга и, как правило, выполняют различные виды поисковых задач. Поскольку соединения и подзапросы используют слияние потоков данных из строк различных таблиц, их роли частично совпадают при некоторых условиях. Коррелированный подзапрос, который может создавать относительные связи между колонками главной таблицы, иногда может содержать спецификации для получения того же результата, что и соединение, без использования самого соединения. С другой стороны, объединения запросов не используют слияние потоков; напротив, они «собирают» строки. Их роль никогда не совпадает с ролью запросов соединения или подзапросов.

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

Соединения

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

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

Подзапросы

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

Запросы UNION

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

Соединения

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

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

Тем не менее условия соединения не ограничены столбцами первичного и внешнего ключей; сервер допускает в выходном наборе данных дубликаты строк. Дублированные строки могут стать причиной нежелательного результата. По этому вопросу обратитесь к замечаниям в разд. «Темы оптимизации».

Внутреннее соединение

Следующий оператор соединяет две таблицы, которые связаны через внешний ключ FK правой таблицы (Table2) и первичный ключ PK таблицы Table1:

SELECT

Таblе1.PK,

Table1.COL1,

Table2.PKX,

Table2.COLX

FROM Table1 INNER JOIN Table2

ON Table1.PK = Table2.FK

WHERE… условия-поиска

Это спецификация внутреннего соединения. Вскоре мы рассмотрим внешнее соединение. На рис. 22.1 показаны два потока, как они существуют в таблицах, и генерируемый набор данных.

Рис. 22.1. Внутреннее соединение

Как показывает диаграмма, внутреннее соединение объединяет два потока таким образом, что несоответствующие строки в любом из потоков отбрасываются. Другое название внутреннего соединения — исключающее соединение, поскольку его правила означают, что несоответствующие пары обоих потоков исключаются из выходного набора данных.

Стандарты SQL описывают два варианта синтаксиса внутреннего соединения. Предыдущий пример использует более современный синтаксис SQL-92, отличающийся от более старого, более ограниченного SQL-89, указывая явное соединение, потому что в примере используется явное предложение JOIN для задания условий соединения.

Синтаксис неявного INNER JOIN в SQL-89

В стандарте SQL-89

таблицы, участвующие в соединении, задаются списком с разделяющими запятыми в предложении FROM запроса SELECT. Условия для связи таблиц задаются среди условий поиска предложения WHERE. Не существует специального синтаксиса для указания, какие условия используются для поиска, а какие — для соединения. Предполагается, что условия соединения самоочевидны. Обратившись назад, к введению в предложение JOIN, можно назвать старый синтаксис неявным соединением.

Синтаксис неявного соединения может осуществлять только внутреннее соединение — реализация SQL, которая не поддерживает предложение JOIN, не может выполнять внешнее соединение.

Вот предыдущий пример, который переписан как неявное соединение:

SELECT

Table1.PK,

Table1.COL1,

Table2.PKX,

Table2.COLX

FROM Table1, Table2

WHERE Table1.PK = Table2.FK

AND <условия-поиска>

Неявное соединение поддерживается в Firebird для совместимости с кодом существующих приложений. Оно не рекомендуется для новых приложений, потому что оно несовместимо с синтаксисом других видов соединений и делает поддержку и само- документируемость довольно неуклюжей. Некоторые программы доступа к данным, включая драйверы, могут не обрабатывать правильно синтаксис SQL-89 по причине проблем при синтаксическом анализе в различении условий соединения и условий поиска. Можно предположить, что в будущем стандарте этот синтаксис будет отсутствовать.

Синтаксис явного INNER JOIN в SQL-92

Явное внутреннее соединение является предпочтительным для Firebird и других реляционных СУБД, которые его поддерживают. Если оптимизатор способен вычислить план запроса, то неважно, что синтаксис SQL-92 будет лучше или хуже более раннего синтаксиса, потому что интерпретатор DSQL будет транслировать любой оператор в идентичную двоичную форму для анализа ее оптимизатором.

Явное соединение делает код оператора более читаемым и согласованным с другими стилями соединения, поддерживаемыми SQL-92 и последующими стандартами. Иногда его синтаксис называют синтаксисом условного соединения, потому что структура предложения JOIN. .. ON дает возможность отличать условия соединения от условий поиска. Не удивительно, такое использование термина «условное» может все запутать!

Ключевое слово INNER совсем необязательно и обычно опускается. Присутствие только слова JOIN имеет точно тот же смысл, что и INNER JOIN. (Если слову JOIN предшествуют LEFT, RIGHT или FULL, то это не является внутренним соединением.)

Три или более потока

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

SELECT

Table1.PK,

Table1.COL1,

Table2.PK,

Table2.COLX,

Table3.COLY

FROM Table1 JOIN Table2

ON Table1.PK = Table2.FK

JOIN Table3 ON TABLE2.PKX = Table3.FK

WHERE Table3.STATUS = ‘SOLD’

AND <другие-условия-поиска>

Связи составных ключей

Если одно отношение связано более чем с одним столбцом, используйте ключевое слово AND для разделения каждого условия соединения, как вы делаете в предложении WHERE для множества условий. Возьмем, для примера, таблицу TableA с первичным ключом (PKI, РК2), связанную с таблицей TableB через внешний ключ (FKI, FK2):

SELECT

TableA.COL1,

TableA.COL2,

TableB.COLX,

TableB.COLY

FROM TableA JOIN TableB

ON TableA.PKI = TableB.FKI

AND TableA.PKI = TableB.FK2

WHERE …

Смешивание неявного и явного синтаксисов

Написание операторов, включающих смешивание неявного и явного синтаксисов, невозможно в Firebird 1.5 и допустимо (но обескураживает) в Firebird 1.0.x. Следующий пример показывает, как не надо писать оператор соединения:

SELECT

Table1.PK,

Table1.COL1,

Table2.PK,

Table2.COLX,

Table3.COLY

FROM Table1, Table2

JOIN Table3 ON TABLE 1. PK = Table3.FK

AND Table3.STATUS = ‘SOLD’ /* это условие поиска !! */

WHERE Table1.PK = Table2.FK

AND <другие-условия-поиска>

Внешние соединения

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

Каждое внешнее соединение имеет левую и правую часть, левая часть является потоком, который присутствует в левой части фразы JOIN, а правая часть- потоком, который назван аргументом фразы JOIN. В операторе, содержащем множество соединений, понятия «левый» и «правый» относительны — правый поток одного предложения соединения может быть левым другого предложения. Такое бывает часто, когда спецификации соединения являются «сглаженной» иерархической структурой.

«Левый» и «правый» значимы в логике спецификаций внешнего соединения. Внешнее соединение может быть левым, правым и полным. Каждый тип внешнего соединения создает различный выходной набор данных из тех же входных потоков. Ключевые слова LEFT, RIGHT и FULL достаточны для установления факта, что соединение «внешнее»; ключевое слово OUTER является необязательной частью синтаксиса.

LEFT OUTER JOIN

Левое внешнее соединение (LEFT OUTER^[78] JOIN) в запросе создает набор данных, состоящий из полностью заполненных столбцов, где найдены соответствующие строки (как и во внутреннем соединении), а также частично заполненных строк для каждого экземпляра, где соответствие правой стороны не найдено для ключа левой стороны. Несоответствующие столбцы будут «заполнены» значением NULL. Вот оператор, использующий те же входные потоки, что и наш пример INNER JOIN:

SELECT

Table1.PK,

Table1.COL1,

Table2.PKX,

Table2.COLX

FROM Table1 LEFT OUTER JOIN Table2

ON Table1.PK = Table2.FK

WHERE … <условия-поиска>

На рис. 22.2 показано, как будут объединены потоки для левого соединения.

Рис. 22.2. Левое соединение

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

RIGHT OUTER JOIN

Правое внешнее соединение (RIGHT OUTER JOIN) в запросе создает набор данных, содержащий полностью заполненные столбцы, где были найдены соответствующие строки (как и во внутреннем соединении), а также частично заполненные строки для каждого экземпляра, где существует правая строка, не имеющая соответствия с левым потоком. Не имеющие соответствия столбцы будут «заполнены» значением NULL. Вот оператор, использующий те же входные потоки, что и наш пример INNER JOIN. Необязательное ключевое слово OUTER здесь отсутствует.

SELECT

Table1.PK,

Table1.COL1,

Table2.PKX,

Table2.COLX

FROM Table1 RIGHT JOIN Table2

ON Table1.PK = Table2.FK

WHERE … <условия-поиска>

На рис. 22.3 показано, как будут объединены потоки для правого соединения.

Рис. 22.3. Правое соединение

FULL OUTER JOIN

Полное внешнее соединение (FULL OUTER JOIN) является целиком включающим. Оно возвращает одну строку для каждой пары соответствующих потоков и одну частично заполненную строку для каждой строки из каждого потока, где соответствие не было найдено. Данное соединение объединяет поведение правого и левого соединений.

Рис. 22.4. Полное соединение

Вот оператор, использующий те же входные потоки, что и наш пример INNER JOIN:

SELECT

Table1.PK,

Table1.COL1,

Table2.PKX,

Table2.COLX

FROM Table1 FULL JOIN Table2

ON Table1.PK = Table2.FK

WHERE … <условия-поиска>

На рис. 22.4 показано, как будут объединены потоки для полного соединения.

Перекрестные соединения

Firebird не поддерживает языковых элементов для перекрестного соединения (CROSS JOIN), которое создает набор данных, являющийся декартовым произведением двух таблиц. То есть для каждой строки левого потока выходной поток будет содержать каждую строку из правого потока. В редких случаях, когда вам нужно декартово произведение, вы можете использовать синтаксис SQL-89 без каких-либо критериев соединения в предложении WHERE, например:

SELECT T1.*, Т2.* FROM T1 TABLE1, T2 TABLE2;

Обработчик запросов Firebird иногда внутренне создает перекрестные соединения, когда конструирует «реки» в процессе соединения операций (см. разд. «Темы оптимизации» этой главы).

Естественные соединения

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

Двусмысленность в запросах JOIN

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

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

Firebird не примет запросы соединения, содержащие ссылки на столбцы, которые не имеют полного квалификатора таблицы. Квалификатор таблицы может быть идентификатором таблицы или алиасом таблицы. Начиная с версии 1.5 недопустимо их смешивать. Если вы используете версию 1.0, будьте последовательны, если хотите избежать переписывания кода при переходе на новые версии.

Предыдущие примеры использовали идентификаторы таблиц. Использование алиасов таблиц более элегантно и компактно, а для некоторых запросов (см. разд. «Реентерабельные соединения») является обязательным.

Алиасы таблиц

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

! ! !

СОВЕТ. В базе данных диалекта 3, которая была создана с использованием ограниченных идентификаторов (delimited identifiers), комбинированных с символами в нижнем регистре или при смешивании регистров в именовании объектов и/или с использованием «неправильных символов», написание запросов может стать довольно утомительным занятием, часто порождающим ошибки, если не используются алиасы.

. ! .

Алиас может быть использован везде, где он допустим для обозначения имени таблицы, как квалификатор; имена всех таблиц должны быть заменены на алиасы. Смешивание идентификаторов таблиц с алиасами в одном и том же запросе приведет к исключениям в Firebird 1.5 и следующих версиях.

Следующий пример использует идентификаторы таблиц:

SELECT

TABLEA.COL1,

TABLEA.COL2,

TABLEB.COLB,

TABLEB.COLC,

TABLEC.ACOL

FROM TABLEA

JOIN TABLEB ON TABLEA.COL1 = TABLEB.COLA

JOIN TABLEC ON TABLEB.COLX = TABLEC.BCOL

WHERE TABLEA.STATUS = ‘SOLD’

AND TABLEC.SALESMAN_ID = ’44’

ORDER BY TABLEA.COL1;

Тот же пример, использующий алиасы:

SELECT

A.COL1,

A.COL2,

B.COLB,

B.COLC,

C.ACOL

FROM TABLEA А /* задает алиас */

JOIN TABLEB В ON A.COL1 = В.COLA

JOIN TABLEC С ON В.COLX = C.BCOL

WHERE A.STATUS = ‘SOLD’

AND С.SALESMAN_ID = ’44’

ORDER BY A.COL1;

Допустимые имена алиасов таблиц

Используйте любую строку, содержащую до 31 символа, которые допустимы для имен метаданных (т. е. алфавитно-цифровые символы в кодировке ASCII в диапазонах 35-38, 48-57, 64-90 и 97-122). Пробелы, диакритические знаки, имена, заключенные в кавычки, и имена, начинающиеся с цифры, недопустимы.

Внутренний курсор

При чтении в потоке сервер базы данных использует указатель, чей адрес изменяется при продвижении чтения от начала к концу. Этот указатель называется курсором — не путайте с курсором набора, который создается в SQL с помощью DECLARE CURSOR. Внутренние курсоры доступны клиентам только посредством синтаксиса соединений и подзапросов.

Рис. 22.5. Внутренний курсор для соединения двух таблиц

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

В любых многотабличных операциях сервер Firebird поддерживает один внутренний курсор для каждого потока. В предыдущих примерах соединений таблиц TableA и TableB каждая имеет свой курсор. Когда появляется соответствие, сервер создает объединенный образ для выходного потока, копируя потоки с текущего адреса из двух курсоров, как показано на рис. 22.5.

Реентерабельные соединения

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

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

Курсоры для реентерабельных соединений

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

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

SELECT

D1.XD,

D1.PARENTID,

D1.DESCRIPTION AS DEPARTMENT,

D2.DESCRIPTION AS PARENT_DEPT

FROM DEPARTMENT D1

LEFT JOIN DEPARTMENT D2

/* левое соединение обращается к корню дерева, ID 100 */

ON Dl.PARENTID = D2.ID;

На рис. 22.6 проиллюстрировано, как выбираются записи потомков в реентерабельном обращении к таблице DEPARTMENT.

Рис. 22.6. Внутренние курсоры для простого реентерабельного соединения Простой двухуровневый результат показан на рис. 22.7.

Результат этого запроса очень простой — одноуровневая денормализация. Операции получения древовидного результата для таблиц такого вида часто являются рекурсивными, они используют хранимые процедуры для реализации и управления рекурсией^[79].

Рис. 22.7. Результат простого реентерабельного соединения

Подзапросы

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

В Firebird версии 1.5 и выше выражения подзапроса используются тремя способами:

* для получения одной строки или многострочного входного набора для операции INSERT (его синтаксис описан в разд. «Оператор INSERT» главы 20);

* для задания в процессе выполнения выходного столбца только для чтения для запроса SELECT;

* для получения значений или условий для предикатов поиска.

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

Задание столбца при использовании подзапроса

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

Вложенный запрос всегда должен иметь условие в предложении WHERE для ограничения вывода одним столбцом из одной строки (называется скалярным запросом); иначе вы увидите подобное сообщение об ошибке: «Multiple rows in singleton select» (Запрос, который должен вернуть одну строку, вернул множество строк).

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

SELECT

LAST_NAME,

FIRST_NAME,

ADDRESS1,

ADDRESS2,

POSTCODE,

(SELECT START_TIME FROM ROUTES

WHERE POSTCODE = ‘2261’ AND DOW = ‘MONDAY’) AS START_TIME

FROM MEMBERSHIP

WHERE POSTCODE = ‘2261’;

Этот подзапрос указывает одно значение POSTCODE для получения значения поля START_TIME транспортного маршрута (таблица ROUTES). Столбцы POSTCODE в главном запросе и в подзапросе могут быть заменены параметрами. Чтобы сделать запрос более общим и более полезным, мы можем использовать коррелированные подзапросы.

Коррелированные подзапросы

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

В следующем примере связываемые столбцы в главном запросе и в подзапросе являются коррелированными; здесь использованы алиасы таблиц для устранения какой- либо неясности:

SELECT

M.LAST_NAME,

M.FIRST_NAME,

M.ADDRESS1,

M.ADDRESS2,

M.POSTCODE,

(SELECT R.START_TIME FROM ROUTES R

WHERE R.POSTCODE = M.POSTCODE AND M.DOW = ‘MONDAY’) AS START_TIME

FROM MEMBERSHIP M

WHERE . . .

Этот запрос возвращает одну строку для каждого выбранного элемента, независимо от того, существует ли соответствие между полями POSTCODE обеих таблиц. Если нет соответствия, то поле START_TIME будет иметь значение NULL.

Подзапрос или соединение?

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

SELECT

M.LAST_NAME,

M.FIRST_NAME,

M.ADDRESS1,

M.ADDRESS2,

M.POSTCODE,

R. START_TIME

FROM MEMBERSHIP M LEFT JOIN ROUTES R

ON R.POSTCODE = M.POSTCODE

WHERE M.DOW = ‘MONDAY’;

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

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

SELECT

M.LAST_NAME,

M.FIRST_NAME, M.ADDRESS1,

M.ADDRESS2,

M.POSTCODE,

R.START _Т1МЕ

FROM MEMBERSHIP M

JOIN ROUTES R

ON R.POSTCODE = M.POSTCODE

WHERE M.DOW = ‘MONDAY’;

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

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

Когда не надо использовать подзапросы

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

Поиск с использованием подзапроса

Использование существующих предикатов в подзапросах- особенно предиката EXISTS О- обсуждалось в главе 21. Подзапросы могут также быть использованы другими способами в предикатах условий поиска в предложениях WHERE и группирования.

Реентерабельные подзапросы

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

SELECT

AL.COL1,

A1.COL2,

A1. TRANSACTION_DATE

FROM ATABLE A1

WHERE AL.TRANSACTION_DATE = (SELECT MAX(A2.TRANSACTION_DATE) FROM ATABLE A2);

Добавление данных с использованием подзапроса с соединениями

В главе 20 мы рассматривали встроенный метод выборки для передачи данных в оператор INSERT, например,

INSERT INTO ATABLE (

COLUMN2, COLUMN3, COLUMN4)

SELECT BCOLUMN, CCOLUMN, DCOLUMN

FROM BTABLE WHERE

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

INSERT INTO EXTABLE (

TRANDATE, INVOICE_NUMBER, EXT_CUST_CODE, VALUE)

SELECT

INV. TRANSACTION_DATE,

INV. INVOICE_NUMBER,

CUS.EXT_CUS_CODE,

SUM (INVD. PRICE * INVD.NO_ITEMS)

FROM INVOICE INV

JOIN CUSTOMER CUS

ON INV.CUST_ID = CUS.CUST_ID

JOIN INVOICE_DETAIL INVD

ON INVD.INVOICE_ID = INV.INVOICE_ID

WHERE …

GROUP BY . . .;

Оператор UNION

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

Наборы, совместимые для объединения

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

CREATE TABLE CURRENT_TITLES (

ID INTEGER NOT NULL,

TITLE VARCHAR(60) NOT NULL,

AUTHOR_LAST_NAME VARCHAR (40),

AUTHOR_FIRST_NAMES VARCHAR(60),

EDITION VARCHAR(10) ,

PUBLICATION_DATE DATE,

PUBLISHER_ID INTEGER,

ISBN VARCHAR(15) ,

LIST_PRICE DECIMAL(9,2));

/**/

CREATE TABLE PERIODICALS (

PID INTEGER NOT NULL,

PTITLE VARCHAR(60) NOT NULL,

EDITOR_LAST_NAME VARCHAR(40),

EDITOR_FIRST_NAMES VARCHAR (60),

ISSUE_NUMBER VARCHAR (10),

PUBLICATION_DATE DATE,

PUBLISHER_ID INTEGER,

LIST_PRICE DECIMAL (9, 2) ) ;

Эти таблицы совместимы для объединения, потому что мы можем создать запрос для получения наборов с соответствующей «геометрией»:

SELECT ID,

TITLE,

AUTHOR_LAST_NAME,

AUTHOR_FIRST_NAMES,

EDITION VARCHAR (10),

LIST_PRICE

FROM CURRENT_TITLES

UNION SELECT

ID,

TITLE,

EDITOR_LAST_NAME,

EDITOR_FIRST_NAMES,

ISSUE_NUMBER,

LIST_PRICE

FROM PERIODICALS;

UNION, содержащий SELECT * FROM таблица, не будет работать, поскольку структуры таблиц различны — вторая таблица не содержит колонки ISBN.

Использование столбцов времени выполнения в объединениях

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

SELECT

ID,

TITLE as PUBLICATION,

‘BOOK ‘ AS PUBLICATION_TYPE,

CAST (AUTHOR_LAST_NAME || ‘ ‘ || AUTHOR_FIRST_NAMES AS VARCHAR (50) )

AS AUTHOR_EDITOR,

EDITION AS EDITION_OR_ISSUE,

PUBLICATION_DATE DATE,

PUBLISHER_ID,

CAST(ISBN AS VARCHAR(14)) AS ISBN,

LIST_PRICE

FROM CURRENT_TITLES

WHERE …

UNION SELECT

ID,

TITLE,

‘PERIODICAL’,

EDITOR_LAST_NAME || ‘ , ‘ || EDITOR_FIRST_NAMES AS AUTHOR_EDITOR,

CAST (AUTHOR_LAST_NAME || ‘, ‘ || AUTHOR_FIRST_NAMES AS VARCHAR(50)),

ISSUE_NUMBER,

PUBLICATION_DATE,

PUBLISHER_ID, ‘Not applicable’,

LIST_PRICE

FROM PERIODICALS

WHERE …

ORDER BY 2;

Условия поиска и упорядочивания

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

Допустимо только одно предложение упорядочения, оно должно следовать после всех поднаборов. Синтаксис ORDER BY номер (т. е. упорядочение по номеру столбца) требуется для упорядочения объединяемых наборов.

Реентерабельные запросы UNION

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

SELECT

ID,

TITLE,

CAST (‘UNDER $20’ AS VARCHAR(IO)) AS RANGE,

CAST (AUTHOR_LAST_NAME || ‘, ‘ || AUTHOR_FIRST_NAMES AS VARCHAR (50) )

AS AUTHOR,

EDITION,

LIST_PRICE

FROM CURRENT_TITLES CT1

WHERE LIST_PRICE < 20.00

UNION SELECT

ID,

TITLE,

CAST (‘UNDER $40’ AS VARCHAR(IO),

CAST (AUTHOR_LAST_NAME || ‘, ‘ || AUTHOR_FIRST_NAMES AS VARCHAR(50) ) ,

EDITION,

LIST_PRICE

FROM CURRENT_IITLES CT2

WHERE LIST_PRICE >= 20.00 AND LIST_PRICE < 40.00

UNION SELECT

ID,

TITLE,

CAST (‘$40 PLUS’ AS VARCHAR(IO) ) ,

CAST (AUTHOR_LAST_NAME || ‘, ‘ || AUTHOR_FIRST_NAMES AS VARCHAR(50) ) ,

EDITION,

LIST_PRICE

FROM CURRENT_TITLES CT3

WHERE LIST PRICE >= 40.00;

UNION ALL

Если в процессе создания объединенного набора были сформированы дублированные строки, то поведение по умолчанию — исключение из набора дублированных строк. Для включения дубликатов используйте UNION ALL вместо UNION.

Темы оптимизации: планы запросов и оптимизатор

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

Планы и оптимизатор запросов Firebird

Для выполнения оператора SELECT или условия поиска сервер Firebird преобразует оператор в набор внутренних алгоритмов, называемых оптимизированным запросом. Каждый раз, когда оператор подготавливается для выполнения, оптимизатор вычисляет план поиска.

План

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

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

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

Выражения плана

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

Синтаксис выражений плана

Шаблон синтаксиса для фразы PLAN:

<спецификация-запроса> PLAN <выражение-плана>

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

Символы

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

plan-expression := [join-type] (plan-item-list)

join-type := [JOIN] | [SORT] [MERGE]

plan-item-list := plan-item | plan-item, plan-item-list

plan-item := table-identifier access-type | plan_expression

table-identifier := { table-identifier | alias-name } [table-identifier]

access-type := { NATURAL | INDEX (index-list) | ORDER index-name }

index-list := index-name | index-name, index-list

Элементы

Тип соединения (join-type) может быть JOIN или MERGE.

* Тип соединения по умолчанию JOIN (т. е. соединение двух потоков с использованием индекса правого потока для поиска соответствующих ключей в левом потоке).

* MERGE выбирается, если нет используемых индексов. В этом случае два потока сохраняются в соответствующем порядке, а затем сливаются. В пользовательских планах скорость поиска будет увеличена при задании такого типа соединения, когда нет доступных индексов.

Идентификатор таблицы (table-identifier) задает поток. Он должен быть именем таблицы базы данных или алиасом. Если одна и та же таблица будет использована более одного раза, для нее должен быть указан алиас для каждого использования. Алиас должен следовать после имени таблицы при ее первом упоминании. Для спецификации базовых таблиц в просмотре синтаксис предоставляет возможность давать таблицам множество идентификаторов. Планы для просмотров обсуждаются в главе 24.

Тип доступа (access-type) должен быть одним из следующих:

* NATURAL — доступ к строкам осуществляется последовательно, без какого-либо особого порядка. Это тип доступа по умолчанию, он может быть опущен, тем не менее разумно включить его в пользовательский план для документирования;

* INDEX — позволяет указать один или более индексов для вычисления предикатов и проверки условий соединения в запросе;

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

Элемент плана (plan-item) включает в себя план доступа, а также идентификатор таблицы или ее алиас.

Оптимизатор

Если вы не очень хорошо знакомы с планами запросов, вы, вероятно, будете удивлены, как весь этот синтаксис может транслироваться в план. Чуть позже синтаксис станет более осмысленным, когда мы посмотрим на некоторые планы, сгенерированные оптимизатором. Тем не менее в настоящий момент будет полезным посмотреть, как оптимизатор использует «материал» для его операций: соединения и условия поиска, требуемые в операторе, потоки, лежащие в основе спецификации запроса, и доступные индексы.

Факторы в оценке преобразований (вычислений)

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

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

* количество строк в таблицах потоков;

* существует ли критерий выбора, и если да, существует ли доступный или подходящий индекс;

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

Потоки

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

Использование индексов

Сервер Firebird может использовать в запросах индекс для трех видов задач.

* Сравнение: выполняется сравнение на условия равно, больше, меньше или STARTING WITH между значением столбца и константой. Если столбец индексирован, то индексный ключ используется для сокращения просматриваемых строк, делая ненужным сканирование всех строк таблицы данных.

* Соответствие потоков для соединений: если доступен индекс для столбцов, указанных в качестве условия соединения для потока с одной стороны соединения, то поток другой стороны будет отыскиваться первым, а его столбцы соединения будут проверяться на соответствие с помощью индекса.

* Сортировка и группирование: если условия в ORDER BY или GROUP BY указывают столбец, который индексирован, то этот индекс будет использован для поиска строк в нужном порядке, а операция сортировки не потребуется.

Формирование двоичного образа потоков

Когда критерий соединения использует индексированный столбец, сервер Firebird генерирует двоичный образ каждого выбранного потока. Затем, используя логику И/ИЛИ в соответствии с критерием поиска, индивидуальные потоки двоичных образов строк объединяются в единый двоичный образ, который описывает все подходящие строки. Если запросу нужно сканировать один и тот же поток за множество проходов, сканирование двоичного образа выполняется гораздо быстрее, чем повторный просмотр индексов.

Двоичное представление языка

В основе обработчика SQL Firebird лежит его родной язык двоичного представления (Binary Language Representation, BLR) и интерпретатор, состоящий из лексического анализатора, синтаксического анализатора, таблицы символов и генератора кода. Обработчик DSQL и включенные приложения передают BLR оптимизатору, и именно BLR, а не строки анализирует оптимизатор. Может случиться такое, что два разных оператора SQL интерпретируются в идентичные BLR.

! ! !

СОВЕТ. Если вам любопытно, на что похож BLR, вы можете использовать инструмент qli (в каталоге Firebird bin) для просмотра операторов. Запустите qli и выдайте команду SET BLR для включения отображения BLR. Документ по qli в формате PDF может быть загружен с различных сайтов Firebird, в том числе с http://www.ibphoenix.com.

Если у вас есть операторы SELECT в хранимой процедуре или триггере, вы можете просмотреть их в isql, выдав команду SET BLOB 2 и выбрав столбец

RDB$PROCEDURE BLR из таблицы RDB$PROCEDURES.

. ! .

Соединения без индексов

Если не существует доступного индекса для условий соединения, оптимизатор задает сортированное слияние двух потоков. Сортированное слияние включает сортировку обоих потоков, а затем одновременное сканирование обоих потоков для их слияния в реку. Сортировка обоих потоков исключает необходимость постоянного сканирования правого потока для поиска соответствия ключам левого потока.

Реки

Рекой является поток, получающийся при слиянии двух потоков в результате соединения. Когда соединения являются вложенными, река может стать потоком для последующих операций. Различные стратегии слияния потоков в реки сравниваются по стоимости. Полученный в результате план использует лучшую стратегию, которую оптимизатор может определить для соединения пар потоков в порядке слева направо.

При вычислении стоимости стратегии соединения оптимизатор определяет весовые коэффициенты для порядка, в котором соединяются потоки. Альтернативные определения порядка больше подходят к внутренним соединениям, чем к внешним. Полные соединения требуют особой обработки.

Размер конкретной реки находится после того, как будет определена наибольшая ветвь в процессе оценки соединения. Оптимизатор выбирает наибольшую ветвь — максимальное количество пар потоков, которые могут быть соединены напрямую. Предпочитаемый метод доступа- сканирование самого большого потока (в идеале самого левого потока) и просмотр в цикле меньших потоков.

При этом более важным, чем размер ветви соединения, является способ, каким читаются строки из правого потока. Тип доступа оценивается в соответствии с доступными индексами и их атрибутами (селективностью) в сравнении с естественным порядком и спецификациями сортировки, представленными в общей картине расчетов.

Если лучший индекс доступен для самого короткого потока, выбор самого большого потока в качестве управляющего потока может быть менее важным, чем экономия стоимости при выборе самого короткого потока с индексом высокой селективности (в идеале уникальный индекс). В этом случае подходящие строки в искомом потоке могут быть получены в результате одного прохода, а неподходящие строки игнорируются.

Примеры планов

Многие графические инструменты администратора базы данных имеют средства для просмотра планов оптимизатора при подготовке оператора. Собственная утилита Firebird isql предоставляет две интерактивные команды для просмотра планов.

Просмотр планов в isql

SET PLAN

В интерактивной сессии isql вы можете использовать SET PLAN С необязательными ключевыми словами ON или OFF для переключения режима отображения плана в начале консольного вывода:

SQL>SET PLAN;

SQL>SELECT FIRST_NAMES, SURNAME FROM PERSON

CON>ORDER BY SURNAME;

PLAN (PERSON ORDER XA SURNAME)

FIRST NAMES

SURNAME

George Stephanie

Abraham Allen

SET STATS

В другой команде переключателя вы можете для isql установить отображение некоторых статистических данных запроса в конце выводимых данных, которые могут оказаться очень полезными при тестировании альтернативных структур запроса и его планов:

SQL>SET STATS ON;

SQL> запускаете ваш запрос>

PLAN..

<вывод>

Current memory = 728316

Delta memory = 61928

Max memory = 773416

Elapsed time =0.17 sec

Buffers = 2048

Reads = 15

Writes = 0

Fetches = 539

SET PLANONLY

Альтернативная команда переключателя SET PLANONLY [ON | OFF] подготавливает оператор и отображает план без выполнения запроса:

SQL>SET PLAN OFF;

SQL>SET PLANONLY ON;

SQL>SELECT FIRST_NAMES, SURNAME FROM PERSON

CON>ORDER BY SURNAME;

PLAN (PERSON ORDER XA_SURNAME)

Если вы собираетесь использовать план оптимизатора в качестве стартовой точки для конструирования пользовательского предложения PLAN, то имейте в виду, что синтаксис выводимого выражения идентичен требуемому синтаксису для выражения плана в операторе^[80]. Неудобным является то, что в isql не существует возможности выводить план оптимизатора в текстовый файл.

! ! !

СОВЕТ. Графические инструменты, которые отображают планы, обычно предоставляют средства копирования/вставки.

. ! .

Следующие примеры используют запросы, которые вы сами можете проверить, используя тестовую базу данных employee.fdb, инсталлированную в ваш каталог примеров^[81].

Простейший запрос

Этот запрос просто отыскивает все строки из таблицы соответствия в произвольном порядке. Хотя оптимизатор определяет наличие индекса (индекс первичного ключа), он его не использует для поиска:

SQL>SET PLANONLY ON;

SQL> SELECT * FROM COUNTRY;

PLAN (COUNTRY NATURAL)

Упорядоченный запрос

Это все еще простой запрос без соединений:

SQL>SELECT * FROM COUNTRY ORDER BY COUNTRY;

PLAN (COUNTRY ORDER RDB$PRIMARYl)

Оптимизатор выбирает индекс первичного ключа, потому что он имеет запрашиваемое упорядочение; при этом не требуется создание промежуточного потока для сортировки.

Теперь давайте посмотрим, что произойдет, когда мы решим упорядочить тот же самый запрос по неиндексированному столбцу:

SELECT * FROM COUNTRY ORDER BY CURRENCY;

PLAN SORT ((COUNTRY NATURAL))

Оптимизатор выбирает выполнение сортировки, просматривая таблицу COUNTRY В естественном порядке.

Перекрестное соединение

Перекрестное соединение, которое обычно создает бесполезный набор, вовсе не использует критериев соединения:

SQL> SELECT Е.*, P.* FROM EMPLOYEE Е, PROJECT Р;

PLAN JOIN (Р NATURAL,Е NATURAL)

Оно просто сливает каждый поток в левой части с каждым потоком правой части. Оптимизатор не использует индексы. Однако этот пример полезен в качестве введения в соединение между алиасами двух таблиц в спецификации соединения и их использовании в плане.

Алиасы, указанные в запросе, используются в плане, выводимом оптимизатором. Для совместимости при создании пользовательского плана хорошей идеей является использование того же способа идентификации таблиц, как и в запросе. При этом, несмотря на то, что синтаксический анализатор не допускает смешивания идентификаторов таблиц и их алиасов в запросах, предложение PLAN допускает любое смешивание^[82]. Например, следующий вариант является приемлемым. Обратите внимание, что оптимизатор допускает использование и идентификаторов таблиц в предложении PLAN.

SQL> SELECT Е.*, P.* FROM EMPLOYEE E, PROJECT P

CON> PLAN JOIN (PROJECT NATURAL, EMPLOYEE NATURAL);

PLAN JOIN (P NATURAL, E NATURAL)

Соединение с индексированными ключами равенства

Такое соединение денормализует отношение один-ко-многим — каждый служащий имеет одну или более записей истории заработной платы:

SELECT Е.*, S.OLD_SALARY, S.NEW_SALARY

FROM EMPLOYEE E

JOIN SALARY_HISTORY S

ON S.EMP_NO = E.EMP_NO;

PLAN JOIN (S NATURAL, E INDEX (RDB$PRIMARY7))

Оптимизатор выбирает цикл по (потенциально) самому длинному детальному потоку для

поиска релевантных строк с использованием индекса уникального первичного ключа таблицы EMPLOYEE. В этом примере либо количество строк в каждой таблице будет приблизительно равным, либо количество строк в таблице SALARY_HISTORY не превысит количество строк в таблице EMPLOYEE в той мере, чтобы не достичь преимуществ уникального индекса в качестве ключа соответствия. Это внутреннее соединение, и оптимизатор разумно предполагает, что именно правый поток определит размер реки.

Давайте посмотрим, как оптимизатор трактует те же самые потоки, когда соединение является внешним левым:

SELECT Е. *, S.OLD_SALARY, S.NEW_SALARY

FROM EMPLOYEE E

LEFT JOIN SALARY_HISTORY S

ON S.EMP_NO = E.EMP_NO;

PLAN JOIN (E NATURAL, S INDEX (RDB$FOREIGN21))

В этот раз одна строка будет возвращена для каждой строки правого потока, независимо от того, будет ли существовать соответствующий ключ в управляющем потоке. Размер реки здесь не имеет значения, поскольку внешние соединения однозначно определяют, какая таблица должна быть в левой стороне, чтобы по ней проводить цикл просмотра. Это алгоритм внешнего соединения, который определяет метод доступа, не измеряющий потоки. С таблицей EMPLOYEE В левой части не существует возможности создать внешнее соединение путем просмотра таблицы SALARY_HISTORY с поиском в EMPLOYEE.

Поскольку оптимизатор не делает выбора относительно того порядка, в котором будут соединяться потоки, он просто выбирает наиболее подходящий индекс из SALARY_HISTORY.

Когда размер имеет значение

В следующем примере размер таблицы не виден при использовании индекса уникального первичного ключа. Таблица DEPARTMENT содержит 21 строку, таблица PROJECT — 6 строк, и оптимизатор выбирает меньший индекс внешнего ключа для оптимизации поиска соответствия по большей таблице:

SELECT * FROM DEPARTMENT D

JOIN PROJECT P

ON D.MNGR_NO = P. TEAM_LEADER ;

PLAN JOIN (D NATURAL,P INDEX (RDB$FOREIGN13))

Соединение с индексированным предложением ORDER BY

Использование индексированных спецификаций упорядочения может повлиять на то, как оптимизатор выбирает навигацию по потокам. Возьмем следующий пример:

SQL> SELECT P.*, E.FULL_NAME FROM PROJECT P JOIN EMPLOYEE E

ON E.EMP_NO = Р. TEAM_LEADER ORDER BY P.PROJ_NAME ;

PLAN JOIN (Р ORDER RDB$11, E INDEX (RDB$PRIMARY7))

Уникальный индекс для EMPLOYEE выбирается по причине неявного условия фильтра в критерии соединения. Запрос сокращает количество служащих, которые не являются руководителями, а уникальный индекс позволяет исключить сканирование таблицы EMPLOYEE. Выбор индекса фильтрации может также повлиять на необходимость использования навигационного индекса в PROJ_NAME для сортировки^[83].

Оптимизатор выбирает индекс правой стороны, потому что правый поток будет того же размера, что и левый или (потенциально) большего размера. Опять же, оптимизатор не может сказать, что это отношение является отношением один к одному. Столбец PROJ_NAME, задающий порядок выходного набора, имеет уникальный индекс, созданный ограничением UNIQUE, чтобы использовать для сортировки, и оптимизатор выбирает этот индекс. Индекс сортировки появляется в плане первым, указывая серверу на необходимость сортировки левого потока перед тем, как он будет отыскивать соответствие ключа соединения в правом потоке.

Соединение равенства при отсутствии доступных индексов

Таблицы в следующем запросе являются неиндексированными копиями таблиц PROJECT и EMPLOYEE (см. сноску 4 ранее в этой главе):

SQL> SELECT PI.*, EL. FULL_NAME FROM PROJECT1 PI JOIN EMPLOYEEL EL ON EL.EMP_NO = PL.TEAM_LEADER ORDER BY PI. PROJ_NAME;

PLAN SORT (MERGE (SORT (EL NATURAL) , SORT (PI NATURAL)))

Потоки с обеих сторон будут сортироваться, а затем сливаться, полученная река снова будет сортироваться, потому что ни один из потоков не имеет требуемого порядка сортировки.

Трехстороннее соединение с индексированными равенствами

Рассмотрим тройное эквисоединение в следующем примере:

SQL> SELECT P.PROJ_NAME, D.DEPARTMENT, PDB. PROJECTED_BUDGET FROM PROJECT P

JOIN PROJ_DEPT_BODGET PDB ON P.PROJ_ID = PDB.PROJ_ID JOIN DEPARTMENT D ON PDB.DEPT_NO = D.DEPT_NO;

PLAN JOIN (D NATURAL, PDB INDEX (RDB$FOREIGN18), P INDEX (RDB$PRIMARY12))

Поскольку доступно множество подходящих индексов, оптимизатор выбирает метод доступа JOIN. Индекс, связывающий поток PDB с таблицей DEPARTMENT, будет использован для выбора потока DEPARTMENT. При обработке результирующей реки и потока PROJECT эквисоединение между первичным ключом таблицы PROJECT и большей по размеру (потенциально) реки дает возможность формировать реку с использованием индекса первичного ключа PROJECT для выборки данных из реки.

Трехстороннее соединение

только с одним индексированным равенством

Для этого примера мы используем неиндексированные копии таблиц PROJECT и EMPLOYEE для демонстрации того, как оптимизатор будет использовать доступный индекс, когда он может применять лучший вариант условий неиндексированного эквисоединения:

SQL> SELECT PI.PROJ_NAME, DL.DEPARTMENT, PDB.PROJECTED_BUDGET FROM PROJECT1 PI

JOIN PROJ_DEPT_BUDGET PDB ON PI . PROJ_ID = PDB.PROJ_ID

JOIN DEPARTMENT1 Dl ON PDB. DEPT_NO = Dl. DEPT_NO;

PLAN MERGE (SORT

(PI NATURAL), SORT (JOIN (Dl NATURAL, PDB INDEX (RDB$FOREIGN18))))

В самом внутреннем цикле выбран индекс внешнего ключа для эквисоединения потока PDB и выбираемых подходящих строк потока DEPARTMENT. Заметьте, что выбор такого индекса ничего не выполняет с внешним ключом, для поддержки которого был создан индекс, поскольку таблица, на которую ссылается внешний ключ, даже не присутствует в операторе.

После этого результирующая река и поток PROJECT сортируются. В завершение (в самом внешнем цикле) два сортированных потока объединяются в один.

Запросы с множеством планов

Когда в запросе задаются подзапросы и объединения, используется несколько операторов SELECT. Оптимизатор конструирует независимый план для каждого оператора SELECT. Возьмем следующий пример:

SELECT

P.PROJ_NAME,

(SELECT E.FULL_NAME FROM EMPLOYEE E

WHERE P.TEAM_LEADER = E.EMP_NO) AS LEADER_NAME

FROM PROJECT P

WHERE P.PRODUCT = ‘software’

PLAN (Е INDEX (RDB$PRIMARY7) )

PLAN (Р INDEX (PRODTYPEX))

Первый план выбирает индекс первичного ключа таблицы EMPLOYEE для просмотра кодов TEAM_LEADER в первичной таблице подзапроса. Индекс PRODTYPEX для таблицы PROJECT используется для фильтрации строк в таблице PRODUCT, поскольку первым элементом ключа в этом индексе является столбец PRODUCT.

Интересно то, что если изменить тот же запрос, включив предложение упорядочения, то оптимизатор изменит свой выбор индекса для фильтрации и выберет уникальный индекс по PROJ_NAME для навигации по упорядочиваемому столбцу:

SELECT

P.PROJ_NAME,

(SELECT E.EULL_NAME FROM EMPLOYEE E

WHERE P.TEAM_LEADER = E.EMP_NO) AS LEADER_NAME

FROM PROJECT P

WHERE P.PRODUCT = ‘software’ ORDER BY 1;

PLAN (E INDEX (RDB$PRIMARY7))

PLAN (P ORDER RDB$11)

Задание вашего собственного плана

Синтаксис выражений, который использует оптимизатор для создания плана и передачи его серверу Firebird доступен в SQL в предложении PLAN. Это позволяет вам определять ваш собственный план, ограничивая оптимизатор в его выборе.

Предложение PLAN может быть задано почти в любом операторе SELECT, включая операторы, используемые в создании просмотров, в хранимых процедурах и подзапросах. Firebird версии 1.5 и выше также допускает предложения PLAN и в триггерах. Множество планов может быть указано независимо для запроса и любого подзапроса. При этом нет требования «все или ничего» — любое предложение плана является необязательным.

Предложение PLAN генерируется для оператора SELECT В хранимой процедуре выбора. Поскольку выходом хранимой процедуры выбора является виртуальный набор, любые условия будут основываться на доступе NATURAL. При этом любой оператор SELECT в хранимой процедуре будет оптимизирован, и для него можно применять пользовательский план.

! ! !

ПРИМЕЧАНИЕ. Конструирование пользовательского плана для оператора SELECT в просмотре создает собственные проблемы для разработчика. Более подробную информацию см. в разд. «Использование планов запросов для просмотров» главы 24.

. ! .

Вы должны задать имена и порядок использования для всех индексов, которые будут использованы.

Оптимизатор всегда создает план, даже если задан пользовательский план. Хотя оптимизатор не мешает созданному пользователем плану, он проверяет, какие индексы подходят для данного контекста. Альтернативные пути отбрасываются, но во всем остальном дела идут своим чередом. Таким образом, наличие пользовательского плана не отключает оптимизатор, и он все равно делает свою оценку и генерацию своего плана в тех аспектах, которые не были указаны в предложении PLAN.

Неверный индекс приведет к тому, что запрос не будет выполнен. Если любой предикат или условие соединения остаются после того, как все индексы, указанные в плане выражения, будут использованы, оптимизатор просто оценит потоки в соответствии с естественным порядком и порядком сортировки по умолчанию.

Представляя ваше собственное выражение плана, вы можете получить небольшое увеличение скорости за счет обхода работы оптимизатора. При этом разработка вашего собственного плана, основанная на структурных правилах управления вашими данными, может не дать ожидаемых вами удовлетворительных результатов, особенно если ваш план наследован от другой СУБД, которая использует структурные правила для оптимизации запросов.

Оптимизатор Firebird основан на стоимости (cost-based) и обычно создает лучший план, если ваша база данных хорошо поддерживается сервисными средствами. Поскольку геометрия индексов и данных может изменяться в процессе выполнения операторов — особенно, если изменяется или удаляется большое количество строк- никакой сгенерированный оптимизатором план не может оставаться статичным от одной подготовки запроса к другой. Если вы создаете статичное выражение PLAN, то ухудшение эффективности может стать результатом снижения производительности, что уберет все преимущества отмены работы оптимизатора.

Смысл сказанного здесь в том, что использование вашего собственного плана может оказаться палкой о двух концах. В процессе разработки вы можете чувствовать преимущество от использования плана, который, как вы верите, является лучшим, чем тот, который будет получен оптимизатором. В этом случае вы отключаете преимущества динамического оптимизатора, который может компенсировать последующие изменения в распределении данных или индексов.

Улучшение плана запроса

Скверно выполняющиеся запросы в Firebird наиболее часто являются следствием плохого задания индексов и неоптимальных запросов. В разд. «Тема оптимизации» главы 18 мы рассматривали влияние индексов с плохой селективностью. В настоящем разделе мы продолжим рассмотрение индексов и некоторых неприятностей, которые могут происходить с оптимизатором и разработчиком, когда индексы служат помехой эффективности поиска.

Аккуратное индексирование

Не факт, что использование индексов в соединении или поиске сделает запрос более быстрым. В действительности существуют такие структуры метаданных и виды индексов, при которых выбор некоторых индексов резко снизит производительность в сравнении с естественным сканированием.

Дублирующиеся или перекрывающие друг друга индексы могут повлиять на использование оптимизатором других индексов. Удалите все индексы, которые дублируют автоматически создаваемые индексы для первичных или внешних ключей или для ограничений UNIQUE. Пары составных первичных и внешних ключей, особенно длинных или несущих смысловое содержание, могут сделать запросы уязвимыми с точки зрения производительности, привести к неправильному выбору индексов и к немалым человеческим ошибкам. При проектировании таблиц рассматривайте использование суррогатных ключей для отделения «осмысленных» столбцов для поиска и упорядочения от формального ключа для соединений.

Составные индексы

Составные (сложные) индексы — это индексы, которые содержат более одного столбца. Хорошо продуманный составной индекс может увеличить скорость запросов и поиска в сложных конъюнктивных запросах (использующих логический оператор AND), особенно для больших таблиц или при низкой собственной селективности отыскиваемого столбца.

В составных индексах важным является ранг (количество элементов и относительная позиция слева направо). Оптимизатор может использовать один столбец составного индекса или подгруппу столбцов в операциях поиска, соединения или упорядочения, не включая оставшиеся столбцы индекса в операции. На рис. 22.8 представлены доступные для оптимизатора возможности по использованию составного индекса (COL1, C0L2, COL3).

Рис. 22.8. Возможности частичного индексного ключа

Если составной индекс может быть выгодно использован на месте одного или более индексов, состоящих из одного столбца, то имеет смысл создавать и тестировать такой индекс. Не существует преимущества в создании составных индексов для дизъюнктивных условий (использующих логический оператор OR) — они не будут использованы. Не поддавайтесь искушению создать составной индекс в надежде, что «один индекс подойдет во всех случаях». Создавайте индексы для определенных потребностей и будьте готовы уничтожить любой из них, который не будет работать хорошо.

На практике основным является рассмотрение полезности составных индексов с точки зрения наиболее вероятных потребностей вывода. Чем больше вы будете порождать избыточных составных индексов, тем более вероятность того, что вы будете получать неоптимальные планы. Элементы ключей в составных индексах часто перекрывают те же элементы в других индексах, заставляя оптимизатор выбирать между двумя или более конкурирующими индексами. Оптимизатор не может гарантировать выбор лучшего из индексов во всех случаях, он может даже решить вовсе не использовать индексы в случаях, когда он не может выбрать лучший из них.

Убедитесь в правильности ваших предположений по поводу эффективности добавления составного индекса путем тестирования не только одного запроса, а также всех регулярных или больших задач поиска, которые включают один или более тех самых столбцов^[84].

! ! !

СОВЕТ. Не будет плохой идеей сохранить все индексные структуры, которые вы тестировали, вместе с записями об их эффектах. Это поможет снизить накал страстей в тестирующей лаборатории!

. ! .

Индексы из одного столбца

Индексы из одного столбца являются гораздо более гибкими, чем составные индексы. Они являются предпочтительными для всех условий, которые не имеют особых потребностей в составных индексах, они также нужны для каждого отыскиваемого столбца, который является частью дизъюнктивного условия (содержащего логическую операцию OR).

Естественный порядок

Не расстраивайтесь, увидев NATURAL В плане запроса, и не бойтесь его использовать при тестировании ваших планов. Естественный (natural) порядок задает сканирование таблицы сверху вниз, страница за страницей. Зачастую это бывает быстрее для некоторых данных, особенно при нахождении соответствия и поиске по столбцам, для которых индекс имеет очень низкую селективность, а также для статичных таблиц с небольшим количеством строк.

Выбор порядка соединения

При соединении двух или более потоков порядок, в котором эти потоки отыскиваются, бывает более важным, чем все другие факторы вместе взятые. Потоки извлекаются в порядке слева направо и являются, вместе с крайним левым потоком конкретного (парного) объединения, «важнейшим контроллером», который определяет логику поиска для всех остальных соединений и слияний, связанных с ним.

В идеале этот управляющий поток отыскивается один раз. Потоки, которые соединяются с ним, отыскиваются итеративно, пока не будут найдены все соответствующие строки. Отсюда следует, что поток, имеющий самую высокую стоимость поиска, должен быть помещен слева от «дешевого» потока в управляющей позиции. Последний поток в списке соединения будет просматриваться множество раз — убедитесь, что это будет самый дешевый по поиску поток.

Обман оптимизатора

В ситуациях, когда оптимизатор выбирает индекс, который вы хотели бы проигнорировать, вы можете обмануть его, добавив пустое условие OR. для простого примера предположим, что у вас есть предложение WHERE, задающее столбец с очень низкой селективностью индекса, который вы хотели бы сохранить, например, для поддержания ссылочной целостности:

SELECT …

WHERE PARENT_COUNTRY = ‘AD’

Если эта база данных распространяется в Австралии (код страны ‘AO’), то селективность PARENT_COONTRY будет настолько низкой, что полностью обрушит производительность, однако вы привязаны к обязательному индексу. Чтобы оптимизатор проигнорировал индекс, измените предикат поиска на^[85]:

SELECT …

WHERE PARENT COUNTRY = ‘AU’ OR 1=1

Использование интуиции

Получение «картины» соединения не является точной наукой, в процессе работы вы получите интуитивное понимание создания спецификаций соединений. Однако с этой техникой борются многие люди. Для всех спецификаций запросов, особенно для запросов к множеству таблиц, секрет заключается в добросовестном их проектировании. Если у вас мало опыта в SQL, не полагайтесь на инструменты CASE или утилиты конструирования запросов, чтобы научиться их создавать. Это классическая ситуация: пока вы не приобретете опыт, вы не сможете оценить, насколько глупы данные инструменты. Если вы всегда полагаетесь на тупые инструменты, вы никогда не приобретете интуицию.

Ознакомьтесь с характеристиками производительности, являющимися результатом структур и содержимого ваших данных. Поймите нормализацию вашей базы данных и распознайте самый короткий путь от ваших таблиц к вашим выходным спецификациям. Используйте карандаш и бумагу для отображения и формирования списка соединений и условий поиска, чтобы они точно и без потерь соответствовали спецификациям вывода.

Пора дальше

Выходные наборы чаще всего не будут полезны конечным пользователям, если они будут упорядочены или сгруппированы малоосмысленными способами. В следующей главе рассматриваются возможности SQL по упорядочиванию наборов и по агрегированию промежуточных выходных наборов в объединенные или статистические группы.

ГЛАВА 23. Упорядоченные и агрегатные наборы.

В этой главе мы рассмотрим синтаксис и правила задания запросов, которые выводят упорядоченные и сгруппированные наборы.

Наборы, заданные оператором SET, по умолчанию читаются в произвольном порядке. Часто, особенно при отображении данных для пользователя или при печати отчетов, вам нужен определенный вид сортировки. Ясно, что список телефонов будет более полезным, если фамилии будут находиться в алфавитном порядке. Группы чисел по продажам или тестовые результаты более понятны, если они упорядочены, сгруппированы и просуммированы. В SQL существует два предложения по заданию формирования выходных наборов.

Предложение ORDER BY используется для сортировки наборов в возрастающем или убывающем порядке по одному или большему количеству столбцов. Предложение GROUP BY может разделять набор на вложенные группы, или уровни, в соответствии со столбцами из списка SELECT и (по желанию) выполняя агрегатные вычисления на множестве числовых столбцов в границах группы.

Обсуждение сортировки

Хотя упорядочение и агрегирование являются операциями с различными результатами, на некотором уровне они взаимодействуют, когда обе используются в запросе и расположение их предложений является важным. Внутри системы они применяют некоторые общие характеристики в отношении формирования промежуточных наборов и использования индексов.

Задание порядка в предложениях сортировки

Следующая упрощенная структура синтаксиса оператора SELECT показывает позицию предложений ORDER BY и GROUP BY В спецификациях упорядочения или группирования. Оба предложения являются необязательными и оба могут присутствовать в операторе:

SELECT [FIRST m] [SKIP N] | [DISTINCT | ALL ]

{<список-столбцов>}

FROM <спецификация-таблицы>

[WHERE <условие-поиска>]

[GROUP BY <элемент-группировки> [COLLATE последовательность-сортировки]

[, <элемент-группировки> [COLLATE последовательность-сортировки ]…]

[HAVING <условие-поиска>]

[UNION [ALL] <выражение-выбора>]

[PLAN <выражение-плана>]

[ORDER BY <список-сортируемых-элементов>]

[FOR UPDATE [OF столбец [,столбец …]] [WITH LOCK]];

Временное пространство сортировки

Запросы с предложениями ORDRE BY и GROUP BY «паркуют» промежуточные наборы для дальнейших операций сортировки во временном хранилище. Рекомендуется иметь доступную память, приблизительно в 2.5 раза превышающую размер самой большой таблицы, которую вы будет сортировать. Версии Firebird 1.5 и выше могут конфигурировать память для сортировки в RAM; всем версиям нужно иметь временное дисковое пространство для использования в этих операциях.

Оперативная память для сортировки

В версии 1.5 и выше по умолчанию устанавливается размер блока памяти сортировки в 1 Мбайт. Это размер каждого участка памяти RAM, который выделяется сервером вплоть до максимального значения по умолчанию 64 Мбайт для Суперсервера и 8 Мбайт для Классического сервера. Оба эти значения могут быть сконфигурированы с помощью параметров конфигурации sortMemBiocksize и sortMemupperLimit, соответственно, в файле firebird.conf.

! ! !

ВНИМАНИЕ! Не слишком увеличивайте ресурсы памяти для кэша сортировки на машине с Классическим сервером. Поскольку Классический сервер порождает отдельный серверный процесс для каждого соединения, слишком большое значение верхней границы приведет к огромному размеру потребляемой памяти RAM в сильно загруженной системе.

. ! .

Место на диске для сортировки

Если на диске не выделена память для сортировки, то сервер будет сохранять файлы сортировки в каталоге /tmp файловой системы POSIX или в каталоге, указанном переменными окружения TMP и/или TEMP в Windows.

Вы можете явно сконфигурировать пространство для сортировки двумя способами. Первый заключается в установлении каталога с использованием переменной окружения FIREBIRD_TMP (INTERBASE_TMP для версии 1.0.x). Второй способ- сконфигурировать каталоги с использованием параметра конфигурации TempDirectories в firebird.config для версии 1.5 и выше или при добавлении одной или более записей temp directory в файл isc config (POSIX) или ibconfig (Windows) для версии 1.0.x.

Инсталляция по умолчанию не выполняет никакого явного конфигурирования размера памяти сортировки на диске. Подробности и синтаксис таких установок см. в разд. «Параметры для конфигурирования памяти сортировки» главы 36.

Индексирование

Упорядоченные наборы являются дорогостоящими для ресурсов сервера и вообще для производительности. При оценке запроса и определении плана оптимизатор может выбирать между тремя методами доступа к наборам данных (называемым потоками), которые располагаются в указанных таблицах: NATURAL (поиск без какого-либо порядка), INDEX (использование индекса для управления поиском) и MERGE (создание двоичных образов двух потоков и их слияние по принципу один к одному).

Когда набор читается в порядке индекса, порядок чтения является неестественным (т. е. не в порядке хранения). Вероятность того, что индексное чтение будет вовлекать в обработку множество страниц, очень высока, а стоимость растет с ростом размера таблицы. В худшем случае количество операций ввода/вывода будет увеличиваться.

При методе MERGE (также называемый SORT) каждая строка (а следовательно, и каждая страница) читается только один раз, а чтение выполняется в порядке хранения. В Firebird 1.5, который с большой вероятностью будет использовать оперативную память для сортировки, метод MERGE является наиболее быстрым в большинстве случаев.

Следует еще раз подчеркнуть важность хорошего индексирования для ускорения и улучшения процесса сортировки в упорядоченных запросах. В упорядоченных наборах при правильных условиях метод INDEX С хорошим индексом быстро выдаст первые строки. При этом индекс также может значительно замедлить выборку. Затраты могут быть такими, что весь набор будет выбран гораздо медленнее, чем при использовании альтернативного метода доступа MERGE. В методе MERGE первая строка отыскивается медленнее, но весь набор выбирается быстрее.

То же самое соотношение необязательно должно применяться к группируемым запросам, поскольку они требуют полной выборки набора на сервере, прежде чем строка может быть выведена. В условиях группирования может случиться так, что индекс ухудшит, а не улучшит производительность.

Предложение ORDER BY

Предложение ORDER BY используется для сортировки выходного набора запроса SELECT, оно также допустимо для любого оператора SELECT, который способен отыскивать множество строк для вывода. Оно помещается после всех других предложений, за исключением предложения FOR UPDATE (если присутствует) или предложения INTO (в хранимой процедуре).

Общая форма синтаксиса предложения ORDER BY:

. . .

ORDER BY <список-элементов-сортировки>

<список-элементов-сортировки> = <элемент-сортировки>

[, <элемент-сортировки>]

<элемент-сортировки> = <столбец> | <выражение> | <номер-позиции>

[COLLATE <порядок-сортировки>]

ASC[ENDING] | DESC[ENDING]

[NULLS LAST [ NULLS FIRST]

Элементы сортировки

Разделенный запятыми <список-элементов-сортировки> определяет вертикальный порядок сортировки строк. Порядок сортировки по каждому элементу сортировки может быть возрастающим (ASC) или убывающим (DESC). Возрастающий порядок является порядком по умолчанию и не обязательно должен быть указан.

Firebird 1.5 поддерживает размещение значений NULL, если присутствуют, в элементе сортировки. Значение по умолчанию, NULLS LAST, означает, что строки NULL будут помещены в конец списка. Задавайте NULLS FIRST для размещения NULL перед всеми другими значениями.

Когда присутствует несколько элементов сортировки, то горизонтальный порядок элементов в предложении является значимым — сортировка выполняется слева направо.

Столбцы

Элементами сортировки обычно являются столбцы. Индексированные столбцы сортируются много быстрее, чем неиндексированные. Если сортировка использует множество столбцов в непрерывной последовательности слева направо, то составной индекс, созданный из таких сортируемых элементов в той же последовательности слева направо с соответствующим направлением сортировки (ASC/DESC), может резко повысить скорость сортировки.

В запросах UNION и GROUP BY столбец, используемый для сортировки, должен присутствовать в выходном списке. В других запросах невыводимые столбцы и (в версии 1.5) выражения, содержащие невыводимые столбцы, допустимы для критерия упорядочения.

Оператор в примере 23.1 показывает сортировку по столбцам в простейшей форме.

Пример 23.1. Простейшая сортировка по столбцам

SELECT COLA, COLB, COLC, COLD

FROM TABLEA

ORDER BY COLA, COLD;

Использование алиасов таблиц

При спецификации упорядоченного набора, который использует соединение или коррелированные подзапросы, вы должны указывать полные идентификаторы для всех элементов сортировки, являющихся столбцами базы данных, или обращаться к столбцам базы данных, используя идентификаторы таблиц или алиасы, которые были заданы в предложениях FROM и JOIN, как показано в примере 23.2.

Пример 23.2, Алиасы таблиц в предложении упорядочения

SELECT A.COLA, A.COLB, B.COL2, B.C0L3

FROM TABLEA А

JOIN TABLEB В ON A.COLA = B.COL1

WHERE A.COLX = ‘Sold’

ORDER BY A.COLA, B.COL3;

Выражения

В Firebird 1.5 и выше правильные выражения допустимы в качестве элементов сортировки, даже если выражение не выводится в виде выходного столбца. Вы можете сортировать наборы по выражениям внутренних и внешних функций или скалярным значениям коррелированных подзапросов (пример 23.3). Если столбец выражения, по которому вы хотите выполнять сортировку, присутствует в выходном списке, вы не можете использовать его имя алиаса в качестве элемента упорядочения. или повторите выражение в предложении ORDER BY, или используйте порядковый номер столбца (см. разд. «Порядковые номера»).

Пример 23.3. Упорядочение по полю выражения

SELECT EMP_NO || ‘-‘ || SUBSTRING (LAST_NAME FROM 1 FOR 3) AS NAMECODE

FROM EMPLOYEE

ORDER BY EMP_NO || ‘-‘ || SUBSTRING (LAST_NAME FROM 1 FOR 3);

Альтернативный способ — замена выражения в предложении упорядочения на порядковый номер поля выражения:

SELECT EMP_NO || ‘-‘ || SUBSTRING (LAST_NAME FROM 1 FOR 3) AS NAMECODE

FROM EMPLOYEE

ORDER BY 1;

Если вам нужна сортировка по выражению в версии 1.0.x, необходимо включить выражение в выходной список и использовать его порядковый номер в предложении

ORDER BY.

Сортировка по выражениям процедур или функций

Сортировка по значениям, возвращаемым обычными или внешними функциями или хранимыми процедурами, похожа на другие виды сортировки: она будет выполняться в соответствии с обычными правилами для типов данных возвращаемых значений. Вы ответственны за указание сортировки только по значениям, которые соответствуют некоторой логической последовательности. В качестве примера неправильной последовательности рассмотрим следующее:

. . .

ORDER BY CAST (SALES_DATE AS VARCHAR(24))

Строки будут упорядочены в алфавитно-цифровой последовательности символов без соответствия датам, с которыми оперирует это выражение.

! ! !

ВНИМАНИЕ! При использовании выражений в качестве критериев упорядочения помните о значительном расходовании ресурсов на сервере при дублировании вычисления выражения для каждой найденной строки. Влияние этого будет в лучшем случае непредсказуемым. Умеренно используйте в этом типе операции количество наборов.

. ! .

Порядковые номера

Особый вид выражения, который может быть задан в качестве критерия сортировки, является порядковым номером в списке выходных столбцов. Порядковый номер является позицией столбца в выходном списке, подсчитываемой слева направо, начиная с единицы. В примере 23.4 снова используется простой запрос из примера 23.1, где используются порядковые номера вместо идентификаторов столбцов.

Пример 23.4. Подстановка порядковых номеров вместо имен столбцов

SELECT COLA, COLB, COLC, COLD

FROM TABLEA

ORDER BY 1, 4;

Предложение упорядочения для сортировки выхода запроса объединения (union) может использовать только порядковые номера для ссылки на столбцы упорядочивания, как показано в примере 23.5.

Пример 23.5. Упорядочивание наборов UNION

SELECT

T.FIRST_NAME, T.LAST_NAME, ‘YES’ AS «TEAM LEADER?»

FROM EMPLOYEE T

WHERE EXISTS(SELECT 1 FROM PROJECT P1

WHERE PI.TEAM_LEADER = T.EMP_NO)

UNION

SELECT

E.FIRST_NAME, E.LAST_NAME, ‘NO ‘ AS «TEAM LEADER?»

FROM EMPLOYEE E

WHERE NOT EXISTS(SELECT 1 FROM PROJECT P2

WHERE P2 .TEAM_LEADER = E.EMP_NO)

ORDER BY 2, 1;

В версии 1.0.x упорядочивание по порядковым номерам является единственным способом использования выражений в качестве критерия сортировки, а столбцы, полученные из выражений, должны быть представлены в спецификации вывода (см. пример 23.6). В версии 1.5 у вас есть вариант использования выражения в качестве элемента сортировки без включения элемента выражения в выходной набор, как показано в примере 23.7.

Пример 23.6. Любая версия

SELECT

FULL_NAME, STRLEN (FULL_NAME)

FROM EMPLOYEE

ORDER BY 2 DESC;

Пример 23 7 Firebird 1 5 и выше

SELECT FULL_NAME FROM EMPLOYEE

ORDER BY STRLEN(FULL_NAME) DESC;

Использование порядкового номера полезно для сохранения контроля типов данных и устранения помех, когда выходной набор включает соединения, поскольку все столбцы базы данных, объявленные как критерий упорядочения, должны иметь полностью определенные идентификаторы.

Сортировка по порядковому номеру не увеличивает скорость выполнения запроса; сервер заново вычисляет выражения для операции сортировки.

Направление сортировки

По умолчанию сортировка выполняется в возрастающем порядке. Для выполнения сортировки в убывающем порядке добавьте ключевое слово DESC, как показано в примере 23.8. Если вам нужна убывающая сортировка, создайте для нее убывающий индекс. Firebird не может «инвертировать» возрастающий индекс и использовать его для убывающей сортировки, так же как он не может использовать убывающий индекс для возрастающей сортировки.

Пример 23.8. Убывающий порядок сортировки

SELECT FIRST LU * FROM DOCUMENT

ORDER BY STRLEN(DESCRIPTION) DESC

Размещение пустых значений

По умолчанию Firebird помещает сортируемые столбцы, имеющие NULL, В конец выходного набора. Начиная с версии 1.5, вы можете использовать ключевое слово NULLS FIRST для указания того, что строки с NULL будут помещаться в начало набора, как показано в примере 23.9.

! ! !

ПРИМЕЧАНИЕ. Никакой индекс не может быть использован для сортируемого элемента, если указано NULLS FIRST.

. ! .

Пример 23.9. Размещение пустого значения

SELECT * FROM EMPLOYEE

ORDER BY PHONE_EXT NULLS FIRST

Предложение GROUP BY

Когда запрос включает предложение GROUP BY, TO спецификация столбца и таблицы, а именно:

SELECT {<список-столбцов>}

FROM <спецификация-таблицы>

[WHERE <условие-поиска>]

передается следующей стадии обработки, где строки разделяются на одну или более вложенных групп.

Обычно каждая часть создает некоторый итог, используя выражения, которые выполняют некоторые операции над группой числовых значений. Такой тип запроса называется группирующим запросом, а его результат часто называется сгруппированным набором.

Его синтаксис:

SELECT <список-группируемых-полей> FROM <спецификация-таблицы>

[WHERE…]

GROUP BY <группирующий-элемент> [COLLATE последовательность-сортировки]

[, <группирующий-элемент> [. . ] ]

HAVING <предикат-группируемых-столбцов>

[ORDER BY .. .] ;

Список группируемых полей

Группа формируется путем объединения (агрегирования) всех строк, где столбец, указанный в списке столбцов и в предложении GROUP BY, имеет общее значение. Логика агрегирования означает, что заданный в SELECT список полей группирующего запроса резко ограничен полями, указанными в качестве аргументов в предложении GROUP BY. Поля, имеющие спецификации, соответствующие этим требованиям, часто называются группируемыми. Если вы задаете столбец или выражение поля, которые не являются группируемыми, то запрос будет отменен.

* Столбец базы данных или неагрегатное выражение не могут быть указаны в списке столбцов, если они не указаны в предложении GROUP BY.

* Агрегатное выражение, оперирующее со столбцом базы данных, который не находится в предложении GROUP BY, может быть включено в список столбцов. Строго рекомендуется использовать алиас для результата такого выражения.

! ! !

ВНИМАНИЕ! В Firebird 1.0.x и InterBase требования к допустимости группирования являются менее ограничивающими. Группирующие запросы и клиентские вызовы хранимых процедур могут вызывать исключения, которые ранее не появлялись. Это давняя ошибка, о которой вы должны знать при миграции ваших старых приложений в Firebird версии 1.5 и выше.

. ! .

Агрегатные выражения

В Firebird существует группа агрегатных (обобщающих) функций, которые обычно используются вместе с условиями группирования для вычисления итогов и статистики на уровне группы.

Агрегатными функциями являются SUMO, которая вычисляет итоги, MINO и MAXO, отыскивающие наименьшее и наибольшее значение соответственно, и AVGO, вычисляющая среднее значение. Функция COUNT() также ведет себя как агрегатная функция в группирующих запросах, возвращая счетчик строк для всех строк ниже контекста (уровня)группы.

В отличие от других группируемых элементов агрегатное выражение в списке SELECT не может быть использовано как элемент группы (см. разд. «Элемент группирования»), поскольку оно возвращает значение, которое вычисляется из значений на нижнем уровне группы.

Таблица PROJ_DEPT_BUDGET содержит строки пересечения проектов и отделов. Мы заинтересованы в отыскании итога по бюджетам, выделенным каждому проекту, независимо от отдела. Следующий список элементов, который рассматривался ранее в этом разделе, задает список полей из двух нужных нам элементов:

SELECT

PROJ_ID,

SUM(PROJECTED_BUDGET) AS TOTAL_BUDGET

FROM PROJ_DEPT_BUDGET

WHERE FISCAL_YEAR = 1994

GROUP BY PROJ_ID;

Эти две спецификации поля хороши в качестве группируемых элементов. Идентификатор отдела (DEPT_NO) не присутствует в списке, потому что список задает нужные нам по проекту итоги. Для получения этих итогов мы используем аргумент PROJ_ID В предложении GROUP BY.

С другой стороны, если мы хотим получить список бюджетов отделов, независимых от проектов, список полей должен включать DEPT_NO, чтобы он был аргументом в предложении GROUP BY:

SELECT

DEPT_NO,

SUM(PROJECTED_BUDGET) AS TOTAL_BUDGET

FROM PROJ_DEPT_BUDGET

WHERE FISCAL_YEAR = 1994

GROUP BY DEPT_NO;

Влияние NULL на агрегатные выражения

В агрегатных выражениях типа SUMO, AVG() и COUNT(<имя-столбца>) строки, содержащие NULL в соответствующем столбце, игнорируются. Функция AVG() создает числитель, суммируя все непустые значения, и знаменатель, подсчитывая строки, содержащие непустые значения.

! ! !

ПРИМЕЧАНИЕ. Если у вас есть столбцы, по которым вы собираетесь вычислять среднее значение, важно решить в процессе проектирования, как при вычислении среднего значения вы будете трактовать «пустые» экземпляры — как NULL (они будут исключены из вычисления) или как ноль. Вы можете реализовать нужное правило, используя значение по умолчанию или (лучше) триггер BEFORE INSERT^[86].

. ! .

Группирующий элемент

Предложение GROUP BY получает список группирующих элементов:

* в Firebird 1.0.x группирующим элементом может быть только имя столбца или соответствующее выражение внешней функции (UDF);

* Firebird 1.5 расширил диапазон группирующих элементов, добавив также номер, порядковое числительное, представляющее номер позиции (слева направо) соответствующего элемента из списка полей SELECT. Этот номер может быть использован вместе с существующей возможностью для аргументов ORDER BY;

* версии Firebird 1.5 и более поздние также имеют возможность группировать по большинству функциональных выражений, таких как CAST(). EXTRACT(),

SUBSTRING(), UPPER(), CASE() и COALESCE().

Следующий оператор завершает создание запроса, начатого в предыдущем примере:

SELECT PROJ_ID,

SUM(PROJECTED_BUDGET) AS TOTAL_BUDGET

FROM PROJ_DEPT_BUDGET

WHERE FISCAL_YEAR = 1994

GROUP BY PROJ_ID;

PROJ_ID TOTAL_BUDGET

GUIDE 650000.00

HWRII 520000.00

MAPDB 111000.00

MKTPR 1480000.00

VBASE 2600000.00

Ограничение

Группирующим элементом не может быть выражение, включающее агрегатную функцию, такую как AVG(), SUM(), MAX(), MIN() или COUNT() — они выполняют обобщение в том же группирующем контексте (на том же уровне), что и группирующий элемент. Это ограничение включает любые агрегатные выражения, которые встроены внутрь другого выражения. Например, синтаксический анализатор DSQL будет «ругаться», если вы попытаетесь сделать следующее:

SELECT

PROJ_ID,

SUM(PROJECTED_BUDGET) AS TOTAL_BUDGET

FROM PROJ_DEPT_BUDGET

WHERE FISCAL_YEAR = 1994

GROUP BY 2;

ISC ERROR CODE:335544569

Cannot use an aggregate function in a GROUP BY clause

(Нельзя использовать агрегатную функцию в предложении GROUP BY)

Использование COUNTQ в качестве агрегатной функции

Очень «вредная» функция COUNT() используется разумно в группирующем запросе для подсчета количества для групп. Рассмотрим следующую модификацию нашего примера. Столбец DEPT_NO в наших требованиях не является подходящим кандидатом ни для группирующего, ни для группируемого элементов, однако он может дать информацию о таких элементах в контексте группирования по PROJ_ID:

SELECT PR0J_ID,

SUM (PROJECTED_BUDGET) AS T0TAL_BUDGET,

COUNT (DEPT_N0) AS NUM_DEPARTMENTS

FROM PROJ_DEPT_BUDGET

WHERE FISCAL_YEAR = 1994

GROUP BY PROJ_ID;

PROJ_ID	TOTAL_BUDGET	NUM_DEPARTMENTS
======	======	======
GUIDE	650000.00	2
HWRII	520000.00	3
MAPDB	111000.00	3
MKTPR	1480000.00	5
VBASE	2600000.00	3

Неагрегатные выражения

Возможность использования для группирования выражений внутренних и внешних функций открывает широкий диапазон возможностей преобразования хранимых атрибутов для генерации выходных наборов, которые нельзя получить другим путем.

Например, внутренняя функция EXTRACT() оперирует с типами данных даты и времени и возвращает части даты — числа, которые выделяют год, месяц, день, час и т.д. из подобных типов данных. Следующий пример для версии 1.5 запрашивает таблицу MEMBERSHIP и выводит статистику, показывающую количество участников, объединенных в каждом месяце, независимо от года или для даты их объединения:

SELECT

MEMBER_TYPE,

EXTRACT (MONTH FROM JOINJDATE) AS MONTH_NUMBER, /* 1, 2, и т.д. */

COUNT (JOIN_DATE) AS MEMBERS_JOINED

FROM MEMBERSHIP

GROUP BY

MEMBER_TYPE, EXTRACT(MONTH FROM JOIN_DATE);

Большое количество полезных функций доступно в библиотеках внешних функций для преобразования дат, строк и чисел в элементы для группирования. Следующий пример иллюстрирует группирование при использовании некоторых функций, найденных в поставляемой библиотеке ib udf:

SELECT STRLEN(RTRIM(RDB$RELATION_NAME)),

COUNT(*)

FROM RDB$RELATIONS

GROUP BY STRLEN(RTRIM(RDB$RELATION_NAME))

ORDER BY 2;

Это будет работать в любой версии Firebird.

Отдельные выражения в настоящий момент недоступны в списке GROUP BY. Например, синтаксический анализатор отклоняет группирующий элемент, который содержит символ конкатенации ||. Следовательно, запрос

SELECT

PROJ_ID || ‘-1994’ AS PROJECT,

SUM(PROJECTED_BUDGET) AS TOTAL_BUDGET

FROM PROJ_DEPT_BUDGET

WHERE FISCAL_YEAR = 1994

GROUP BY PROJ_ID || ‘-1994’;

в Firebird 1.5 вернет следующее исключение:

ISC ERROR CODE:335544569

Token unknown — line 6, char 21

Использование порядкового номера поля выражения будет работать без проблем:

SELECT

PROJ_ID || ‘-1994’ AS PROJECT,

SUM(PROJECTED_BUDGET) AS TOTAL_BUDGET

FROM PROJ_DEPT_BUDGET

WHERE FISCAL_YEAR = 1994

GROUP BY 1;

Группирование по порядковому номеру

Использование порядкового номера выходного столбца в предложении GROUP BY «копирует» выражение из списка выбора (как это делает и предложение ORDER BY). Это означает, что когда порядковый номер указывает на подзапрос, этот подзапрос будет выполняться, по меньшей мере, дважды.

Подвыражение HAVING

Подвыражение HAVING является фильтром для сгруппированного вывода, которое работает аналогично тому, как предложение WHERE фильтрует несгруппированный набор.

Условие HAVING использует в точности тот же синтаксис предикатов, что и условие WHERE, но его не следует путать с предложением WHERE. Фильтр HAVING применяется к группам после того, как набор будет разделен. Вам может еще понадобиться предложение WHERE для фильтрации входного набора.

В Firebird 1.0.x вы можете задать условие HAVING С использованием столбцов, которые не включены в состав группируемых элементов — «ленивое предложение WHERE» и «дефект» в терминах стандартных соглашений. Начиная с версии 1.5 в HAVING могут быть использованы только группируемые элементы.

Важно понимать влияние условия HAVING на производительность. Условие обрабатывается после того, как выполнено группирование. Если оно используется вместо условий WHERE для фильтрации ненужных элементов, возвращенных в группах, указанных в списке GROUP BY, то строки будут обрабатываться дважды только для того, чтобы уменьшить их количество.

Чтобы улучшить производительность, используйте условия WHERE для предварительной фильтрации групп, a HAVING используйте для фильтрации результатов, полученных от агрегатных выражений. Например, группа, полученная при использовании выражения SUM(X), может быть отфильтрована с помощью HAVING SUM(X) > <минимальное-значение>. Следовательно, предложение HAVING обычно принимает агрегатное выражение в

качестве своего аргумента.

Взяв предыдущий запрос, мы можем использовать предложение WHERE для фильтрации групп проектов, которые появляются в выходном наборе, и использовать предложение HAVING для установки начального диапазона сумм, которые мы хотим просматривать:

SELECT

PROJ_ID

SUM(PROJECTED_BUDGET) AS TOTAL_BUDGET

FROM PROJ_DEPT_BUDGET

WHERE FISCAL_YEAR = 1994

AND PROJ_ID STARTING WITH ‘M’

GROUP BY PROJ_ID

HAVING SUM(PROJECTED BUDGET) >= 100000;

PROJ_ID TOTAL_BUDGET

MAPDB 111000.00

MKTPR 1480000.00

Предложение HAVING может принимать сложные аргументы, содержащие логические операции AND и OR, которые используют ту же логику приоритетов, что и предложение WHERE.

Подвыражение COLLATE

Если вам нужно сгруппировать текстовый столбец с использованием последовательности сортировки, отличной от той, которая была определена по умолчанию для этого столбца, вы можете включить предложение COLLATE. Подробную информацию о COLLATE см. в разд. «Последовательность сортировки» главы 11.

Использование ORDER BY в группирующем запросе

Начиная с Firebird версии 1.5, элементы в списке ORDER BY В группирующем запросе должны быть либо агрегатными функциями, допустимыми в контексте группирования, либо элементами, которые представлены в списке GROUP BY.

Firebird 1.0.x является менее ограничивающим- он допускает упорядочение по элементам или выражениям, находящимся вне контекста группирования.

Улучшенные условия группирования

Firebird 1.5 и более поздние версии поддерживают некоторые дополнительные условия группирования, недоступные в версии 1.0.x.

Подзапросы во встроенных агрегатах

Группируемое поле, которое связано с выражением подзапроса, может содержать агрегатное выражение, ссылающееся на элемент агрегатного выражения в списке

GROUP BY.

В следующем примере реентерабельный подзапрос к системной таблице RDB$RELATION_FIELDS содержит агрегатное выражение (MAX(I:.RDB$FIELD_POSITION)), результат которого используется для локализации имени (RDB$FIELD_NAME) столбца, имеющего наибольший номер позиции для каждой таблицы (RDB$RELATION_NAME) в базе данных:

SELECT

r.RDB$RELATION_NAME,

MAX(r.RDB$FIELD_POSITION) AS MAXFIELDPOS,

(SELECT

r2,RDB$FIELD_NAME FROM RDB$RELATION_FIELDS r2

WHERE

r2.RDB$RELATION _NAME = r.RDB$RELATION_NAME

and r2.RDB$FIELD_POSITION = MAX(r.RDB$FIELD_POSITION)) AS FIELDNAME

FROM RDB$RELATI ON_FIELDS r

/* мы используем предложение WHERE для фильтрации системных таблиц */

WHERE r,RDB$RELATION NAME NOT STARTING WITH ‘RDB$’

GROUP BY 1;

RDB$RELATION_NAME	MAXFIELDPOS	FIELDNAME
===========	============	=========
COUNTRY	1	CURRENCY
CROSS_RATE	3	UPDATE_DATE
CUSTOMER	11	ON_HOLD
DEPARTMENT	6	PHONE_NO
EMPLOYEE	10	FOLL_NAME
EMPLOYEE_PROJECT	1	PROJ_ID
JOB	7	LANGUAGE_REQ
PHONE_LIST	5	PHONE_NO
PROJECT	4	PRODUCT
PROJ_DEPT_BUDGET	4	PROJECTED_BUDGET
SALARY_HISTORY	5	NEW_SALARY
SALES	12	AGED

Теперь в тех же самых текстах мы используем COUNT() для подсчета количества столбцов, хранимых в каждой таблице:

SELECT

rf.RDB$RELATION_NAME AS «Table Name», (

SELECT

r.RDB$RELATION_ID

FROM RDB$RELATIONS r

WHERE r.RDB$RELATION_NAME = rf.RDB$RELATION_NAME) AS ID,

COUNT(*) AS «Field Count»

FROM RDB$RELATION_FIELDS rf

WHERE rf,RDB$RELATION_NAME NOT STARTING WITH ‘RDB$’

GROUP BY

rf.RDB$RELATION NAME;

Table Name	ID	Field Count
COUNTRY	128	2
CROSS_RATE	139	4
CUSTOMER	137	12
DEPARTMENT	130	7

… и т.д.

Агрегаты во встроенных подзапросах

Выражение агрегатной функции- COUNT(), AVG() и т.д.- может принимать аргумент, который является выражением подзапроса, возвращающим скалярное значение. Например, далее результат запроса SELECT COUNT(*) передается на более высокий уровень в выражение SUMO, которое для каждой таблицы (RDB$RELATION_NAME) выводит произведение счетчика полей на количество индексов в таблице:

SELECT

r.RDB$RELATION_NAME,

SUM((SELECT COUNT(*) FROM RDB$RELATION_FIELDS rf

WHERE rf,RDB$RELATION_NAME = r.RDB$RELATION_NAME))

AS «Fields * Indexes»

FROM RDB$RELATIONS r

JOIN RDB$INDICES i

ON (i.RDB$RELATION_NAME = r.RDBSRELATION_NAME)

WHERE r.RDB$RELATION_NAME NOT STARTING WITH ‘RDB$’

GROUP BY r.RDB$RELATION_NAME;

RDB$RELATION NAME Fields * Indexes

COUNTRY 2

CROSS_RATE 4

CUSTOMER 48

DEPARTMENT 35

… и т.д.

Агрегаты на смешанных уровнях группирования

Агрегатные функции для различных уровней группирования могут быть перемешаны в одном и том же группирующем запросе.

В следующем примере результат выражения, полученный из подзапроса, который выполняет COUNT() для столбца на самом низком уровне группы (RDB$INDICES), передается на уровень группирования. Предложение HAVING выполняет фильтрацию, определяемую двумя другими агрегатными функциями на нижнем уровне группы.

SELECT

r.RDB$RELATION_NAME,

MAX(i.RDB$STATISTICS) AS «Maxl»,

/* одно агрегатное выражение, вложенное в другое */

(SELECT COUNT(*) || ‘ — ‘ || MAX(i.RDB$STATISTICS)

FROM RDB$RELATION_FIELDS rf

WHERE rf.RDB$RELATION_NAME = r.RDB$RELATION_NAME) AS «Max2»

FROM

RDB$RELAT IONS r

JOIN RDB$INDICES i

ON (i.RDB$RELATION NAME = r.RDB$RELATION_NAME)

WHERE r.RDB$RELATION_NAME NOT STARTING WITH ‘RDB$’

GROOP BY

r.RDB$RELATION_NAME

HAVING

MIN(i.RDB$STATISTICS) MAX(i.RDB$STATISTICS);

RDB$RELATION NAME Maxl Max2

MTRANSACTION 000000000000001 18 — 1.000000000000000

MEMBER 0.0135135138407 12 — 0.01351351384073496

! ! !

ВНИМАНИЕ! Вы можете получить результат при выполнении этого запроса в Firebird 1.0.x, однако он будет некорректным.

. ! .

Вложенные агрегатные функции

Агрегатное выражение может быть вложено внутрь другого агрегатного выражения, если внутренняя агрегатная функция находится на более низком уровне (контексте), что иллюстрируется предыдущим запросом.

Пора дальше

В этой главе по языку манипулирования данными мы рассмотрели возможности SQL по трансформации абстрактных данных, хранимых в таблицах, в информацию, которую конечный пользователь читает в осмысленных контекстах. При некоторых условиях есть смысл сохранять постоянные определения полезных выходных наборов (виртуальных таблиц), чтобы не изобретать колесо каждый раз, когда требуется похожий набор. В следующей главе рассматриваются способы осуществления этого, в том числе и возможности просмотров.

ГЛАВА 24. Просмотры.

В терминологии SQL-89 и SQL-92 просмотр является стандартным типом таблицы, он также называется просматриваемой или виртуальной таблицей. Он характеризуется как виртуальный, потому что вместо того, чтобы хранить табличный объект и выделять страницы для хранения данных, сервер Firebird сохраняет только описание метаданных объекта. Оно содержит уникальный идентификатор, список спецификаций столбцов и компилированный оператор SELECT для поиска описанных в этих столбцах данных во время выполнения.

Что такое просмотр?

По своей природе просмотр является спецификацией таблицы, которая не хранит данные. Он действует как фильтр для столбцов и строк таблиц, на которые ссылается просмотр, — «окно», через которое просматриваются фактические данные. Запрос, определяющий просмотр, может обращаться к одной или более таблицам или к другим просмотрам базы данных. Во многих случаях он ведет себя как постоянная таблица и инкапсулирует некоторые специальные расширения для связи с лежащими в его основе таблицами.

Вы вызываете просмотр, как если бы он был обычной таблицей, выполняете соединения, упорядочиваете и группируете выход, задаете условия поиска, используете в качестве подзапроса, наследуете столбцы времени выполнения из его виртуальных данных, используете выбранный из него именованный или неименованный курсор и т.д.

Многие запросы могут быть «изменяемыми», позволяя изменять состояние лежащих в их основе постоянных таблиц, или они могут быть сделаны изменяемыми через триггеры. Когда подтверждаются изменения данных в таблицах, содержимое данных просмотра изменяется вместе с ними. При подтверждении изменения данных просмотра данные лежащих в его основе таблиц изменяются соответствующим образом.

Ключи и индексы

Просмотры не могут иметь ключей или индексов. Лежащие в их основе таблицы, называемые базовыми таблицами, будут использованы как источник индексов при конструировании оптимизатором планов запроса. Тема плана запроса для запросов, включающих просмотры, весьма запутана. Она обсуждается позже в этой главе в разд. «Использование планов запроса для просмотров».

Упорядочение и группирование строк

Определение просмотра не может быть упорядоченным. Добавление предложения ORDER BY вызывает исключение. Следовательно, не имеет смысла использовать в операторе SELECT ключевых слов FIRST и/или SKIP, поскольку они оперируют с упорядоченными наборами.

Спецификация группирования запроса (с использованием допустимого предложения GROUP BY) является нормальной практикой.

Некоторые простые спецификации просмотров

Просмотр может быть создан практически из любой спецификации запроса SELECT. Примеры приведены в следующих разделах.

Вертикальное подмножество столбцов одной таблицы

Таблица JOB в базе данных employee.fdb имеет восемь столбцов: JOB_CODE, JOB_GRADE, JOB_COUNTRY, JOB_TITLE, MIN_SALARY, MAX_SALARY, JOB_REQUIREMENT и LANGUAGE_REQ.

Следующий просмотр возвращает список диапазонов (подмножество столбцов) для всех работ (все строки) таблицы JOB:

CREATE VIEW JOB_SALARY_RANGES AS

SELECT JOB_CODE, MIN_SALARY, MAX_SALARY FROM JOB;

Горизонтальное подмножество строк одной таблицы

Этот просмотр возвращает только столбцы JOB_CODE и JOB_TITLE только для тех работ, где MAX_SALARY меньше $15 000:

CREATE VIEW ENTRY_LEVEL_JOBS AS

SELECT JOB_CODE, JOB_TITLE FROM JOB

WHERE MAX_SALARY < 15000;

Подмножество строк и столбцов для нескольких таблиц

Следующий пример показывает просмотр, который соединяет таблицы JOB и EMPLOYEE.

EMPLOYEE содержит 11 столбцов: EMP_NO, FIRST_NAME, LAST_NAME, PHONE_EXT, HIRE_DATE, DEPT_NO, JOB_CODE, JOB_GRADE, JOB_COUNTRY, SALARY и FULL_NAME.

Просмотр возвращает два столбца из таблицы JOB и два столбца из таблицы EMPLOYEE, фильтруя записи таким образом, что записи работников, чья зарплата составляет $15 000 и выше. не попадают в выходной набор:

CREATE VIEW ENTRY_LEVEL_WORKERS AS SELECT

E.JOB_CODE,

J.JOB_TITLE,

E.FIRST_NAME,

E. LAST_NAME

FROM JOB J

JOIN EMPLOYEE E

ON J.JOB_CODE — E.JOB_CODE

WHERE E.SALARY < 15000;

Почему просмотры могут быть полезными

Требования к данным индивидуального пользователя или группы пользователей могут быть довольно постоянными. Просмотры предоставляют средства для создания пользовательских версий таблиц, содержащих группы данных, подходящих для отдельных пользователей и их задач. Перечислим преимущества просмотров.

* Упрощенные, повторно используемые пути доступа к данным: просмотры позволяют инкапсулировать подмножество данных одной или более таблиц для использования в качестве основы других запросов.

* Настраиваемый доступ к данным: просмотры предоставляют способ для такой адаптации выхода базы данных, что он будет ориентирован на задачу, будет подходить для специфических навыков и требований пользователей и будет сокращать объем перемещаемых по сети данных.

* Независимость данных: просмотры могут защитить пользовательские приложения от воздействия изменений структуры базы данных. Например, если администратор базы данных решает разделить одну таблицу на две, просмотр может быть создан как соединение этих двух новых таблиц. Приложения могут использовать этот просмотр, как если бы они продолжали обращаться к одной постоянной таблице.

* Безопасность данных: просмотры позволяют ограничить доступ к важным или не относящимся к делу частям таблиц.

Привилегии

Поскольку просмотр является объектом базы данных, он требует специальных привилегий для доступа к нему пользователя. Предоставляя привилегии к просмотру, можно дать пользователям очень детализированный доступ к отдельным столбцам и строкам таблиц, не давая им доступ к другим, более чувствительным данным, хранимым в базовых таблицах. В этом случае просмотру предоставляются привилегии к таблицам, а пользователям — привилегии к этому просмотру.

Привилегии владельца

Пользователь, который создает просмотр, становится его владельцем. При создании просмотра пользователь должен иметь соответствующие привилегии к базовым таблицам.

* Некоторые просмотры по своей природе являются просмотрами только для чтения (см. разд. «Просмотры только для чтения и изменяемые»). Для формирования просмотра только для чтения создателю нужны привилегии SELECT К каждой базовой таблице.

* Для изменяемых просмотров создателю нужны привилегии ALL К базовым таблицам.

В дополнение к этому владельцы базовых таблиц и других просмотров, к которым обращается создаваемый просмотр, должны предоставить все требуемые привилегии для доступа и модификации этих объектов через просмотр самому просмотру. То есть привилегии к этим базовым объектам должны быть предоставлены просмотру.

Владелец просмотра имеет к нему все привилегии, включая возможность предоставлять привилегии к нему другим пользователям, триггерам и хранимым процедурам.

Привилегии пользователя

Создатель просмотра должен предоставить соответствующие привилегии пользователям, хранимым процедурам и другим просмотрам, которым нужен доступ к этому просмотру. Пользователь может получить привилегии к просмотру без доступа к его базовым таблицам.

В случае изменяемых просмотров привилегии INSERT, UPDATE и DELETE должны быть предоставлены всем пользователям, которым нужно выполнять операции DML над базовыми таблицами через просмотр. И наоборот, предоставляйте пользователям только привилегию SELECT, если вы собираетесь создавать просмотр только для чтения.

Если пользователь уже имеет требуемые права к базовым объектам просмотра, он автоматически будет использовать те же права к просмотру.

! ! !

ВНИМАНИЕ! Чем меньше привилегий предоставлено пользователю, тем больше защищены объекты базы данных. При этом потенциально большое количество привилегий в иерархии может вызвать проблемы, если цепь будет разрушена удалением привилегий владельца просмотра. Учитывая привлекательность просмотров в качестве механизма защиты данных от просмотра ненужными людьми, системному администратору следует поддерживать документацию по всем предоставленным привилегиям.

. ! .

Подробное описание привилегий SQL см. в главе 35.

Создание просмотров

Оператором DDL, определяющим запрос, который будет трансформирован в объект просмотра, является CREATE VIEW. Хотя он определяет таблицу (пусть и виртуальную) и позволяет употреблять пользовательские имена для объявления столбцов, его синтаксис не включает никаких определений данных для столбцов. Его структура создается на основе списка столбцов оператора SELECT и таблиц, указанных в предложении FROM, а также в необязательных предложениях JOIN этого оператора.

Все стили соединения (join) и объединения (union) наборов, которые поддерживаются для запросов, также поддерживаются и для просмотров. При этом не существует возможности определять просмотр, который получает выходной набор из хранимой процедуры, недопустимо также включать предложение ORDER BY.

Оператор CREATE VIEW

Синтаксис для CREATE VIEW:

CREATE VIEW имя-просмотра

[(-имя-столбца-просмотра [, имя-столбца-просмотра [,…]])]

<спецификация-выбора> [WITH CHECK OPTION];

Имя просмотра

Имя просмотра уникально идентифицирует просмотр как объект базы данных. Имя не может быть тем же самым, что и имя другого просмотра, таблицы или хранимой процедуры.

Задание имен столбцов просмотра

Задание списка имен столбцов просмотра является необязательным, если не существует дубликатов имен в списке столбцов. По умолчанию будут использованы имена столбцов базовой таблицы (таблиц).

В случае, когда результатом соединения является появление дубликатов имен, то здесь необходимо использовать список, который будет переименовывать столбцы.

Следующий довольно безобразный пример демонстрирует, как могут появиться дубликаты имен столбцов:

CREATE VIEW VJOB_LISTING

SELECT E.*,

J. J0B_C0DE,

J.JOB_TITLE

FROM EMPLOYEE E

JOIN JOB J

ON E.JOB_CODE = J.JOB_CODE ;

ISC ERROR CODE:335544351

unsuccessful metadata update

STORE RDB$RELATION_FIELDS failed

attempt to store duplicate value (visible to active transactions)

in unique index «RDB$INDEX_15»

(ISC ERROR CODE:335544351 неудачное изменение

метаданных невозможно сохранить RDB$RELATION_FIELDS

попытка сохранить дубликат значения (видимый в активных транзакциях) в уникальном индексе «RDB$INDEX_15»)

Индекс RDB$INDEX_15 является уникальным индексом для имени отношения и имени поля. Столбец JOB_CODE из таблицы EMPLOYEE уже сохранен для VJOB_LISTING, отсюда и исключение.

Необходимо именовать все столбцы в этом просмотре:

CREATE VIEW VJOB_LISTING (

EMP_NO, FIRST_NAME, LAST_NAME,

PHONE_EXT, HIRE_DATE, DEPT_NO,

EMP_JOB_CODE, /* альтернативное имя */

JOB_GRADE, JOB_COUNTRY, SALARY, FULL_NAME,

JOB_JOB_CODE, /* альтернативное имя * /

JOB_TITLE)

SELECT

E.*,

J. JOB_CODE,

J. JOB_TITLE

FROM EMPLOYEE E

JOIN JOB J

ON E.JOB CODE = J.JOB_CODE ;

Список также является обязательным, если список столбцов содержит какие-либо поля, полученные из выражений. Например, следующее определение будет ошибочным:

CREATE VIEW VJOB_ALTNAMES

SELECT JOB_СODE || ‘for ‘ || JOB_TITLE AS ALTNAME

FROM JOB;

ISC ERROR CODE:335544569

Invalid command

mast specify column name for view select expression

(ISC ERROR CODE:335544569 Неверная команда,

нужно задать имя столбца для выражения в операторе SELECT в просмотре)

Следующее будет правильным:

CREATE VIEW VJOB_ALTNAMES

(ALTNAME)

SELECT JOB_CODE || ‘ for ‘ || JOB_TITLE

FROM JOB;

Список имен столбцов просмотра должен соответствовать порядку и количеству столбцов, указанных в операторе SELECT.

Задание SELECT

Спецификация SELECT- это обычный оператор SELECT, который может включать соединения, поля выражений, спецификации группирования и условия поиска- но не условия упорядочения.

Выходной список в предложении SELECT определяет типы, позиции и (если не заданы явно) имена столбцов просмотра.

Запрос SELECT DISTINCT также допустим.

Предложение FROM вместе с любыми предложениями JOIN или подзапросами определяет базовые таблицы просмотра.

! ! !

ПРИМЕЧАНИЕ. Выражение SELECT * FROM <отношение> допустимо, однако для просмотров не рекомендуется, если в ваших планах эффективная документируемое?. Если используется такое выражение, то порядок следования столбцов будет соответствовать порядку в базовой таблице. Важно помнить, что вам нужно использовать предложение именования столбцов (см. разд. «Задание имен столбцов просмотра»).

. ! .

Вы можете включить предложение WHERE, если вам нужно задать условия поиска. Также может быть включено предложение GROUP BY вместе с необязательным предложением HAVING.

Определение вычисляемых столбцов

Те же самые правила, которые применяются к любым выражениям для определения полей времени выполнения в запросах, также применимы к столбцам времени выполнения в спецификациях просмотров. Выход просмотра почти такой же, что и вычисляемые столбцы в таблице. При этом вычисляемый столбец имеет свои собственные отличные эффекты в просмотре:

* он требует, чтобы обязательно присутствовал список столбцов;

* он делает запрос неизменяемым.

Предположим, что вы хотите создать просмотр, который выводит гипотетическое увеличение на 10 процентов окладов всех служащих компании. Следующий пример создает просмотр только для чтения, который отображает всех служащих и их возможные новые оклады:

CREATE VIEW RAISE_BY_10

(EMPLOYEE, NEW_SALARY)

SELECT EMP_NO, SALARY * 1.1 FROM EMPLOYEE;

WITH CHECK OPTION

WITH CHECK OPTION является необязательным синтаксическим элементом, используемым только в спецификациях просмотров. Он воздействует на изменяемые просмотры, которые были определены с предложением WHERE. Это воздействие осуществляется на блок любых изменяющих операций, результатом которых может быть нарушение условия поиска в предложении WHERE.

Предположим, вы создаете просмотр, который предоставляет доступ ко всем отделам с бюджетами от $10 000 до $500 000. Просмотр V_SUB_DEPT может быть определен следующим образом:

CREATE VIEW V_SUB_DEPT (

DEPT_NAME,

DEPT_NO,

SUB_DEPT_NO,

LCW_BUDGET)

AS SELECT

DEPARTMENT,

DEPT_NO,

HEAD_DEPT,

BUDGET

FROM DEPARTMENT

WHERE BUDGET BETWEEN 10000 AND 500000

WITH CHECK OPTION;

Пользователь с привилегиями INSERT К этому просмотру может добавлять новые данные в столбцы DEPARTMENT, DEPT_NO, HEAD_DEPT и BUDGET базовой таблицы через этот просмотр, WITH CHECK OPTION гарантирует, что все значения бюджетов, вводимые через этот просмотр, будут находиться в указанном для просмотра диапазоне.

Следующий оператор добавляет новую строку отдела Publications через просмотр

V_SUB_DEPT:

INSERT INTO V_SUB_DEPT (

DEPT_NAME,

DEPT_NO,

SUB_DEPT_NO,

LOW_BUDGET)

VALUES (‘Publications’, ‘999’, ‘670’, 250000);

Однако следующий оператор не будет выполнен, потому что значение LOW_BUDGET выходит за пределы диапазона, заданного для базового столбца BUDGET:

INSERT INTO V_SUB_DEPT (

DEPT_NAME,

DEPT_NO,

SUB_DEPT_NO,

LOW_BUDGET)

VALUES (‘Publications’, ‘999’, ‘670’, 750000);

ISC ERROR CODE:335544558

Operation violates CHECK constraint on view or table V_SUB_DEPT

(ISC ERROR CODE:335544558

Операция нарушает ограничение CHECK для просмотра или таблицы V_SUB_DEPT)

Предложение WITH CHECK OPTION В просмотре может быть полезным, когда вы хотите предоставить пользователям изменяемый просмотр, однако вам нужно не допустить изменения ими некоторых столбцов. Просто включите условие поиска для каждого столбца, который вы хотите защитить. Полезность этого предложения несколько ограничена по той причине, что просмотр не может быть определен с заменяемыми параметрами.

Просмотры только для чтения и изменяемые

Когда над просмотром выполняется операция DML, изменения могут быть переданы базовым таблицам, на основе которых был создан просмотр, только в случае выполнения некоторых условий. Если просмотр соответствует этим условиям, он будет изменяемым. Если он не соответствует этим условиям, то просмотр будет только для чтения, и изменения в просмотре не смогут передаваться базовым таблицам.

Через просмотр значения могут передаваться только тем столбцам, которые были поименованы в просмотре. Firebird сохраняет NULL во всех других столбцах. Просмотр не будет изменяемым, если в нем не указаны столбцы, которые не допускают значения NULL.

Просмотр только для чтения может быть сделан изменяемым с помощью триггеров.

Просмотры только для чтения

Просмотр будет просмотром только для чтения, если его оператор SELECT имеет любую из следующих характеристик:

* указывает квантификатор строк, отличный от ALL (т. е. DISTINCT, FIRST, SKIP);

* содержит поля, определенные через подзапросы или другие выражения;

* содержит поля, определенные через агрегатные функции, и/или содержит предложение GROUP BY;

* включает спецификации UNION;

* соединяет несколько таблиц;

* включает не все столбцы NOT NULL из базовой таблицы;

* выбирает данные из существующего просмотра, который не является изменяемым.

Преобразование просмотров только для чтения в изменяемые

Вы можете написать триггеры, которые будут выполнять корректные изменения в базовых таблицах, когда для просмотра запрашиваются операции DELETE, UPDATE или INSERT. Такая возможность Firebird может перевести неизменяемые просмотры в изменяемые.

Следующий скрипт создает две таблицы, создает просмотр, который является соединением этих двух таблиц, а затем создает три триггера (для операций DELETE, UPDATE, INSERT), которые будут передавать все изменения в просмотре базовым таблицам:

CREATE TABLE Table1 (

ColA INTEGER NOT NULL,

ColB VARCHAR(20),

CONSTRAINT pk_table PRIMARY KEY(ColA) );

COMMIT;

CREATE TABLE Table2 (

ColA INTEGER NOT NULL,

ColC VARCHAR(20),

CONSTRAINT fk_table2 FOREIGN KEY REFERENCES Table1(ColA) ) ;

COMMIT;

CREATE VIEW TableView AS

SELECT Table1.ColA, Table1.ColB, Table2.ColC

FROM Table1, Table2

WHERE Table1.ColA = Table2.ColA;

COMMIT;

SET TERM ^;

CREATE TRIGGER TableView_Delete FOR TableView

ACTIVE BEFORE DELETE AS

BEGIN

DELETE FROM Table1

WHERE ColA = OLD. ColA;

DELETE FROM Table2

WHERE ColA = OLD. ColA;

END ^

CREATE TRIGGER TableView_Update FOR TableView

ACTIVE BEFORE UPDATE AS

BEGIN

UPDATE Table1

SET ColB = NEW.ColB

WHERE ColA = OLD.ColA;

UPDATE Table2

SET ColC = NEW.ColC

WHERE ColA = OLD.ColA;

END ^

CREATE TRIGGER TableView_Insert FOR TableView

ACTIVE BEFORE INSERT AS

BEGIN

INSERT INTO Table1 values (NEW.ColA,NEW.ColB);

INSERT INTO Table2 values (NEW.ColA,NEW.ColC);

END ^

COMMIT ^

SET TERM ;^

При определении триггеров для просмотров проследите, чтобы они не создавали конфликтов или неожиданных условий в отношении триггеров, определенных для базовых таблиц. Выполнение триггера для просмотра предшествует выполнению триггера для таблицы соответствующей фазы (BEFORE/AFTER).

Предположим, у вас есть триггер BEFORE INSERT (перед вставкой) для базовой таблицы, который получает значение генератора для первичного ключа, если его NEW. VALUE имеет значение NULL. ЕСЛИ триггер для просмотра включает оператор INSERT для базовой таблицы, не указывайте столбец первичного ключа в этом операторе в просмотре. Это приведет к тому, что для NEW.VALUE первичного ключа будет передано значение NULL, давая возможность триггеру таблицы выполнить свою работу.

О триггерах и контекстных переменных NEW.* см. главу 31.

Безнадежные случаи

Не все просмотры могут быть сделаны изменяемыми путем создания для них триггеров. Например, следующий удобный маленький просмотр только для чтения читает контекстную переменную с сервера, но несмотря ни на какие триггеры, которые вы определите для него, все операции за исключением SELECT не будут выполняться:

CREATE VIEW SYSTRANS

(CURR_TRANSACTION) AS

SELECT CURRENT_TRANSACTION FROM RDB$DATABASE;

Естественно изменяемые просмотры

Просмотр является естественно изменяемым, если выполняются следующие два условия:

* спецификация просмотра является подмножеством одной таблицы или другого изменяемого просмотра;

* все столбцы базовой таблицы, не включенные в определение просмотра, допускают значение NULL.

Следующий оператор создает естественно изменяемый просмотр:

CREATE VIEW EMP_MNGRS (FIRST, LAST, SALARY) AS

SELECT FIRST_NAME, LAST_NAME, SALARY

FROM EMPLOYEE

WHERE JOB_CODE = ‘Mngr’

WITH CHECK OPTION;

Поскольку предложение WITH CHECK OPTION включено в эту спецификацию, приложения не смогут изменять значение столбца JOB_CODE, даже если не было нарушения ограничения внешнего ключа для этого столбца в базовой таблице.

Изменение поведения изменяемых просмотров

Альтернативное поведение естественно изменяемых просмотров может быть задано с использованием триггеров. Для конкретной фазы операции (BEFORE/AFTER) триггеры просмотра вызываются до триггеров базовой таблицы. Следовательно, можно бережно и умело использовать просмотры для замены поведения обычного триггера базовой таблицы на планируемое.

Однако также можно создать разрушение при наличии плохо спланированных триггеров просмотров. Проверяйте, проверяйте, проверяйте!

Изменить определение просмотра?

Термины изменяемый и только для чтения относятся к тому, как может осуществляться доступ к данным из базовых таблиц, а не к тому, может ли изменяться определение просмотра. Firebird не предоставляет синтаксис ALTER VIEW.

Для изменения определения просмотра вы должны удалить просмотр, а затем заново его создать.

Удаление просмотра

Оператор DROP VIEW позволяет владельцу просмотра удалять его описание из базы данных. Он не влияет на базовые таблицы, связанные с просмотром.

Синтаксис:

DROP VIEW имя-просмотра;

Операция DROP VIEW не будет выполнена, если вы не соединены как владелец просмотра, или если этот просмотр используется в другом объекте, таком как просмотр, хранимая процедура, триггер для другого просмотра, определение таблицы или ограничение CHECK.

Следующий оператор удаляет определение просмотра:

DROP VIEW SOB_DEPT;

Использование просмотров в SQL

В SQL просмотр ведет себя во многих отношениях как обычная таблица. Вы можете осуществлять выборку из него, используя или нет предложения ORDER BY, GROUP BY или WHERE.

Если просмотр является естественно изменяемым, или он был сделан изменяемым с помощью триггера и существуют соответствующие привилегии SQL, вы можете выполнять для него позиционированные и поисковые операции изменения, добавления и удаления, которые будут оперировать с базовой таблицей. Вы можете также делать следующее:

* создавать просмотры просмотров;

* выполнять выбор из просмотра в модулях PSQL;

* выполнять соединение (JOIN) просмотра с другими просмотрами и таблицами. В некоторых случаях вы можете соединять просмотры с хранимыми процедурами выбора.

Для простой иллюстрации создадим просмотр и хранимую процедуру для таблицы EMPLOYEE и выполним их соединение. Вот просмотр:

CREATE VIEW V_EMP_NAMES

SELECT EMP_NO, LAST_NAME, FIRST_NAME

FROM EMPLOYEE ^

COMMIT ^

А вот хранимая процедура:

CREATE PROCEDURE P_EMP_NAMES

RETURNS (

EMP_NO SMALLINT;

EMP_NAME VARCHAR (35))

BEGIN

FOR SELECT EMP_NO, FIRST_NAME || ‘ ‘ || LAST_NAME FROM EMPLOYEE

INTO :EMP_NO, :EMP_NAME

SUSPEND;

END ^

COMMIT ^

Запрос, который их соединяет:

SELECT

V.EMP_NO,

V.LAST_NAME,

V.FI RST_NAME,

P.EMP_NAME

FROM V_EMP_NAMES V

JOIN P_EMPNAMES P

ON V.EMP_NO = P.EMPNO ^

Использование планов запросов для просмотров

Просмотры могут представлять для пользователей некоторые сложности относительно возможности PLAN. В основном пользователи могут трактовать просмотры как обычные таблицы. Однако, если вы захотите определить пользовательский план, вам нужно иметь сведения об индексах и структурах базовых таблиц, участвующих в просмотре.

Оптимизатор трактует ссылку на просмотр так, как если бы базовые таблицы, используемые при создании просмотра, были добавлены в список FROM запроса.

Предположим, просмотр был создан следующим образом:

CREATE VIEW V_PROJ_LEADERS (

PROJ_ID,

PROJ_TITLE,

LEADER_ID,

LEADER_NAME)

SELECT

P.PROJ_ID,

P. PROJ_NAME,

P. TEAM_LEADER,

E.FULL_NAME,

FROM PROJECT P

JOIN EMPLOYEE E

ON P.TEAM_LEADER = E.EMPNO;

Простой запрос к просмотру

SELECT * FROM V_PROJ_LEADERS;

выводит следующий план:

PLAN JOIN (V_PROJ_LEADERS P NATURAL, V_PROJ_LEADERS E INDEX (RDB$PRIMARY7) )

Обратите внимание, что оптимизатор обращается к индексам базовых таблиц (через алиасы р и Е) для лучшего способа поиска в просмотре. Спецификация SELECT в объявлении CREATE VIEW определяет логику выполнения соединения.

Следующий запрос является чуть более сложным. В этот раз просмотр соединяется с таблицей EMPLOYEE PROJECT с помощью первичных ключей таблиц EMPLOYEE и PROJECT. Затем он опять соединяется с таблицей EMPLOYEE для получения ненормализованного списка, который включает имена участников всех проектов, управляемых просмотром:

SELECT

PL.*,

EMP.LAST_NAME

FROM V_PROJ_LEADERS PL

JOIN EKPLOYEE_PROJECT EP

ON PL.PROJ_ID = EP.PROJ_ID

JOIN EMPLOYEE EMP

ON EP.EMP_NO = EMP.EMP_NO;

PLAN JOIN (EMP NATURAL, EP INDEX (RDB$FOREIGN15) , PL P INDEX (RDB$PRIMARY12) ,

PL E INDEX (RDB$PRIMARY?) )

В этот раз индекс внешнего ключа для столбца EMP_NO таблицы EMPLOYEE_PROJECT (с алиасом EP) используется для выбора имен участников проекта из второго «элемента» — EMPLOYEE. Как и в предыдущем случае, соединение внутри просмотра использует первичный ключ таблицы EMPLOYEE для поиска соответствия в TEAM_LEADER.

Если вы решите написать свой план для запроса, который работает с просмотром, вам нужно хорошо знать определение просмотра, понимать индексы и методы доступа.

Известная ошибка в просмотрах в Firebird 1.0.x

Если вы определяете просмотр, который является объединением (union) двух или более наборов, просмотр будет вести себя неправильно при использовании в подзапросе в Firebird 1.0.x. Например, следующий запрос приведет к краху сервера:

SELECT 1 FROM Table1 WHERE EXISTS (

SELECT FIELD1 FROM UNION_VIEW WHERE <условия-поиска> )

Эта ошибка была исправлена до релиза версии 1.5.

Другие наследуемые таблицы

В настоящий момент Firebird поддерживает две другие формы наследуемых таблиц: хранимые процедуры выбора и внешние виртуальные таблицы (External Virtual Table, EVT).

Хранимые процедуры выбора

Расширения Firebird PSQL предоставляют синтаксис для определения хранимой процедуры, которая выводит наследуемый набор данных из чего угодно виртуального: из базы данных, контекстных переменных (даже только из входных переменных), из внешних таблиц или из любой их комбинации. Синтаксис SELECT В PSQL и DSQL предоставляет возможность поиска в этих виртуальных таблицах, как если бы они были реальными таблицами.

Выходной набор хранимой процедуры выбора определяется как набор выходных переменных с использованием предложения RETURNS из оператора CREATE PROCEDURE. Выходные данные создаются в результате цикла по набору курсора, определенному в операторе SELECT, В процессе чтения значений указанных столбцов в эти выходные переменные или в объявленные локальные переменные. Внутри цикла возможно выполнение практически любых операций манипулирования данными, включая использование внутренних циклов. Хранимая процедура выбора может быть вызвана из другой хранимой процедуры. Все, что может быть выбрано, вычислено или наследовано, может преобразовываться в выход.

В качестве простой иллюстрации следующее объявление хранимой процедуры содержит цикл, в котором последовательно передаются строки (по одной за раз) в выходной буфер:

CREATE PROCEDURE SHOW_JOBS_FOR_COUNTRY (

COUNTRY VARCHAR(15))

RETURNS ( /* виртуальная таблица */

CODE VARCHAR (11) ,

TITLE VARCHAR(25),

GRADE SMALLINT)

BEGIN

FOR SELECT job_code, job_title, job_grade FROM job

WHERE JOB_CODNTRY = :COUNTRY

INTO :CODE, :TITLE, :GRADE

BEGIN /* начало цикла */

CODE = ‘CODE: ‘ || CODE; /* немного похулиганить с этим значением */

SUSPEND; /* выводит одну строку цикла */

END

После компиляции хранимой процедуры она готова к выполнению. Получение набора выполняется с помощью слегка измененного оператора SELECT, который при необходимости может принимать константные аргументы в качестве входных параметров:

SELECT * FROM SHOW_JOBS_FOR_COUNTRY (‘England’);

CODE TITLE GRADE

CODE: Admin Administrative Assistant 5

CODE: Eng Engineer 4

CODE: Sales Sales Co-ordinator 3

CODE: SRep Sales Representative 4

Подробнее о создании и использовании хранимых процедур см. в части VII. Хранимые процедуры выбора детально обсуждаются в главе 30.

Внешние виртуальные таблицы

Внешняя виртуальная таблица (EVT) является таблицей, которая получает данные от некоторого внешнего источника данных, а не из базы данных. Результаты запроса к EVT трактуются точно тем же образом, что и результаты любого другого запроса, они выглядят точно так же, как если бы они были получены из таблицы базы данных. Это позволяет интегрировать такие внешние данные, как источники данных реального времени, форматированные данные файлов операционной системы, другие базы данных (включая даже не реляционные базы данных), а также любые другие источники табулированных данных.

Firebird реализует внешние виртуальные таблицы с помощью предложения EXTERNAL FILE оператора CREATE TABLE. Внешние данные читаются из текстовых записей фиксированного формата в обычные столбцы данных Firebird.

Внешние таблицы Firebird могут также добавлять записи во внешние виртуальные таблицы.

См. разд. «Использование внешних файлов в качестве таблиц» главы 16.

Пора дальше

Следующая часть книги имеет дело с ключевой и малодокументированной темой транзакций. Основной акцент относительно внутренних технических подробностей в следующих трех главах делается на том, что чем лучше вы понимаете, что происходит в процессе взаимодействия множества клиентов и сервера, тем более эффективной, интуитивной и продуктивной может быть разработка ваших приложений.

ЧАСТЬ VI. Транзакции.

ГЛАВА 25. Обзор транзакций Firebird.

В базах данных клиент-сервер, таких как Firebird, клиентское приложение никогда не касается данных, которые физически хранятся в страницах базы данных. Вместо этого клиентские приложения ведут общение с системой управления базой данных — с «сервером» — создавая пакеты запросов и ответов внутри транзакций. Эта часть книги посвящена ключевым концепциям и вопросам управления транзакциями в Firebird.

Система управления данными, которые изменяются множеством одновременно работающих пользователей, является уязвимой со стороны большого количества проблем целостности данных, если будет работать без какого-либо контроля. Перечислим такие проблемы.

* Потеря изменений (lost updates) появляется, когда два пользователя просматривают один и тот же набор, и один пользователь выполняет изменения, за которыми сразу же следуют изменения другого пользователя, перекрывающие работу первого пользователя.

* «Грязное» чтение (dirty read) позволяет одному пользователю видеть изменения, которые у другого пользователя находятся в процессе выполнения, без гарантии того, что изменения другого пользователя являются окончательными.

* Невоспроизводимое чтение (non-reproducible-reads) позволяет одному пользователю непрерывно выбирать строки, которые другие пользователи изменяют или удаляют. Эта проблема зависит от среды. Например, финансовые процессы по концу месяца или инвентаризация будут ошибочными в этих условиях, поскольку приложению продажи билетов нужно содержать все пользовательские представления синхронизированными, чтобы исключить двойные заказы.

* Фантомные строки (phanthom rows) появляются, когда один пользователь может выбирать некоторые, но не все новые строки, введенные другими пользователями. Опять же, это может быть применимо в одних ситуациях, однако это будет искажать результаты некоторых процессов.

* Перекрывающиеся транзакции могут возникать, когда изменения строки одним пользователем влияют на данные в других строках в той же таблице или в других таблицах, к которым обращаются другие пользователи. Это обычно связано с синхронизацией, проявляющейся, когда нет способа управлять или предсказать последовательность, в которой пользователи будут выполнять изменения.

Для решения таких проблем Firebird использует модель управления, которая изолирует каждую задачу внутри уникального контекста, ограничивающего последствия, если работа такой задачи может вызвать перекрытие работы, выполненной другими задачами. Состояние базы данных не может изменяться, если существуют какие-либо конфликты.

! ! !

ПРИМЕЧАНИЕ. Firebird не допускает «грязное» чтение. При некоторых условиях он специально позволяет невоспроизводимое чтение.

. ! .

Свойства ACID

Сейчас прошло уже более 20 лет с того времени, как два исследователя, Тэо Хедер (Theo Haerder) и Андреас Рютер (Andreas Reuter), опубликовали обзор, описывающий поддержание целостности базы данных в параллельно изменяемой среде. Они объединили требования в четыре правила, названные атомарность (atomicity), согласованность (consistency), изолированность (isolation) и устойчивость (durability) — аббревиатура ACID^[87]. В течение последующих лет концепция ACID стала эталоном для реализации транзакций в системах баз данных.

Атомарность

Транзакция (называемая также единицей работы) описывается как множество действий, преобразующих данные. Чтобы быть «атомарной», транзакция должна быть реализована таким образом, чтобы обеспечить принцип «все или ничего, когда выполняются либо все операции, либо ни одна из них»^[88]. Транзакция либо завершается полностью (подтверждается, commit), либо отменяется (откатывается, rollback).

Согласованность

Предполагается, что транзакции выполняют корректные преобразования состояния абстрактной системы — т. е. база данных должна оставаться в согласованном состоянии после завершения транзакции, независимо от того, была ли она подтверждена или отменена. Концепция транзакции предполагает, что программисты имеют механизм, позволяющий им объявлять и проверять правила согласованности. Стандарты SQL для реализации этих механизмов на сервере предоставляют триггеры, ограничения ссылочной целостности и ограничения CHECK.

Изолированность

В то время как транзакция изменяет совместно используемые данные, система должна создать для каждой транзакции иллюзию, что она выполняется изолированно; ей

должно казаться, что все другие транзакции выполнялись или до того, как она началась, или после того, как она завершилась. В процессе перехода данных из начального согласованного состояния в конечное согласованное состояние может существовать несогласованное состояние базы данных, но никакие данные не могут быть подвержены изменениям со стороны других транзакций, пока не будут подтверждены изменения данной транзакции.

В главе 26 рассматриваются три уровня изоляции транзакций, реализованные в Firebird вместе со средствами реагирования на конфликты и предотвращения работы транзакции, которая накладывалась бы на работу другой транзакции.

Устойчивость

Когда транзакция завершается, ее изменения должны быть устойчивыми — т. е. новое состояние всех объектов, видимых другим транзакциям после подтверждения, будет сохранено и будет постоянным, независимо от наличия ошибок в оборудовании или краха программного обеспечения.

Контекст транзакции

Завершенное общение между клиентом и сервером называется транзакцией. Каждая транзакция имеет уникальный контекст, что приводит к тому, что транзакция будет изолирована от всех других транзакций указанным способом. Правила для контекста транзакции задаются в программе клиентского приложения, при передаче параметров транзакции. Транзакция стартует, когда клиент сообщает серверу о ее начале, получая с сервера дескриптор транзакции. Она остается активной, пока клиент не подтвердит работу (если это возможно) или не отменит ее.

Одна транзакция, много запросов

В Firebird любая операция, запрашиваемая клиентом, должна появиться в контексте какой-либо активной транзакции. Одна транзакция в своих границах может включать один или много клиентских запросов и ответов сервера. Одна транзакция может использовать более одной базы данных, осуществляя операции чтения и записи во многих базах данных в процессе решения задачи. Задачи, создающие базы данных или изменяющие их физическую структуру (одиночный оператор DDL или пакет таких операторов), также используют транзакции. Клиент и сервер имеют свои роли.

* Роль клиента: клиенты инициируют все транзакции. Когда запущена транзакция, клиент ответственен за передачу запросов на чтение и запись данных, а также за завершение (подтверждение или откат) каждой запущенной им транзакции.

Одно клиентское соединение может иметь много активных транзакций.

* Роль сервера: задачей сервера является отслеживание каждой транзакции и поддержание согласованного вида базы данных для каждой транзакции в ее контексте. Он должен управлять всеми запросами по изменению базы данных так, чтобы

соответствующим образом обрабатывались конфликты и предотвращалось нарушение согласованности базы данных.

Рис. 25.1 в общих чертах иллюстрирует типичный контекст транзакции по чтению и записи от ее начала до завершения. Он показывает, как сервер управляет многими параллельными транзакциями независимо друг от друга, даже если другие транзакции являются активными в том же самом клиентском приложении.

Рис. 25.1. Контекст транзакции и независимость

В этом примере приложение может использовать транзакцию для выбора (чтения) наборов строк, любая из которых может быть выбрана пользователем для изменения или удаления. В той же самой транзакции могут быть добавлены новые строки. Запросы на изменение, добавление или удаление «посылаются» на сервер один за другим в процессе выполнения пользователем его задачи.

Атомарность модели

Возможность для клиентского приложения выдавать множество обратимых запросов внутри одной транзакции Firebird является очевидным преимуществом для задач, требующих

многократного выполнения одного оператора с различными входными параметрами. Это и представляет атомарность для задач, где должна быть выполнена группа операторов, а под конец либо подтверждена как единая работа, либо полностью отменена, если встретилось исключение.

Транзакции и MGA

MGA (Multi-Generational Architecture, многоверсионная архитектура) является названием основной архитектурной модели управления состоянием базы данных Firebird.

В модели MGA каждая строка, сохраняемая в базе данных, содержит уникальный идентификатор той транзакции, которая ее сохранила. Если другая транзакция посылает изменение строки, сервер записывает на диск новую версию этой строки с новым идентификатором транзакции и преобразует образ старой версии в ссылку (называемую дельтой) на эту новую версию. Теперь сервер содержит два «поколения» одной и той же строки.

Пересылка в сравнении с COMMIT

Термин «пересылка» (post), вероятно, был заимствован у старых настольных бухгалтерских программ в качестве аналога пересылаемых журналов в бухгалтерских системах. Такая аналогия полезна для различения двух разделенных операций записи обратимых изменений в базу данных (при выполнении оператора) и подтверждения всех изменений, выполненных одним или несколькими операторами. Отправленные изменения невидимы за пределами их контекста транзакции и могут быть отменены. Подтвержденные изменения являются постоянными и становятся видимыми в запускаемых впоследствии транзакциях.

Если появляется какой-либо конфликт при пересылке, сервер возвращает клиенту сообщение исключения, и подтверждение отменяется. Приложение должно будет обработать этот конфликт в соответствии с его типом. Для конфликта изменения решением часто бывает откат транзакции, следствием чего является отмена всей работы как атомарной единицы. При отсутствии конфликта приложение может подтвердить работу по ее завершении.

! ! !

ПРИМЕЧАНИЕ. Вызовы клиентом COMMIT или ROLLBACK являются единственно возможными способами завершения транзакции, Ошибки при подтверждении не означают, что сервер выполнит откат транзакции.

. ! .

Откат

Откат (rollback) никогда не завершается с ошибкой. Он отменит все изменения, которые были запрошены в процессе выполнения транзакции, — изменения, которые привели к исключениям, так же как и изменения, которые были успешными и не вызвали исключения.

Некоторые отмененные транзакции не оставляют образов строк на диске. Например, некоторые отмены вызывают на сервере просто исчезновение работы, выполненной триггерами, и образы строк, созданные при добавлении данных, естественным образом уничтожаются в процессе отмены вместе с автоматически отмененным протоколом, который поддерживается для добавления. Если одна транзакция добавляет большое количество записей, автоматически отмененный протокол будет уничтожен вместе с результатами, образы которых отмена будет оставлять на диске. Другие условия, при которых образы добавляемых записей могут оставаться на диске, — это крах сервера в процессе выполнения операции или использование установок транзакции, которые явно требуют «не отменять автоматически»^[89].

Блокировка строки

В MGA наличие ожидающих завершения новых версий строки имеет следствием блокировку строки. При большинстве условий наличие новой подтвержденной версии блокирует запрос на изменение или удаление этой строки — это конфликт блокировки.

При получении запроса на изменение или удаление сервер проверяет состояние каждой транзакции, которая «владеет» новыми версиями строки. Если самая новая из этих владеющих транзакций является активной или была подтверждена, сервер отвечает запрашивающей транзакции в соответствии с ее контекстом (уровень изоляции и параметры разрешения блокировки).

Если транзакция самой новой версии является активной, запрашивающая транзакция по умолчанию будет ожидать ее завершения (подтверждения или отката), а затем сервер позволит ей продолжить свое выполнение. При этом если было задано NOWAIT, сервер вернет исключение конфликта запрашивающей транзакции.

Если транзакция самой новой версии подтверждена и запрашивающая транзакция имеет уровень изоляции SNAPSHOT (т. е. параллельный), сервер отвергает запрос и сообщает о конфликте блокировки. Если транзакция имеет уровень изоляции READ COMMITTED с установленным по умолчанию значением RECORD_VERSION, сервер выполняет запрос и записывает новую версию записи с идентификатором этой транзакции.

! ! !

ПРИМЕЧАНИЕ. Возможны другие условия, когда запрашивающая транзакция имеет уровень изоляции READ COMMITTED. На результат любого запроса транзакции могут также воздействовать необычные условия в контексте транзакции, которая владеет ожидающими завершения изменениями. Более подробную информацию об этих вариантах см. в главе 26, где детально рассматриваются параметры транзакции.

. ! .

Firebird не использует традиционную двухфазную блокировку для большинства обычных контекстов транзакции. Следовательно, все нормальные блокировки выполняются на уровне строки (такая блокировка называется оптимистической) — каждая строка доступна всем транзакциям чтения/записи, за исключением транзакции, выполняющей создание новой версии этой строки.

Во время успешного подтверждения старая версия записи становится устаревшей записью.

* Если выполнялась операция изменения, то новый образ становится самой последней подтвержденной версией. Оригинальный образ этой записи с идентификатором последней изменяющей транзакции становится доступным для сборки мусора.

* Если выполнялась операция удаления, то «остаток записи» заменяет устаревшую запись. Чистка или резервное копирование очищает этот остаток и освобождает физическое место на диске, занимаемое удаленной записью.

Сведения о чистке и сборке мусора см. в разд. «Гигиена базы данных» главы 15. Руководство по чистке находится в главе 39.

В итоге при нормальных условиях:

* любая транзакция может читать любую строку, которая была подтверждена до старта этой транзакции;

* любая транзакция чтения/записи может запрашивать изменение или удаление строки;

* пересылка (post) обычно будет успешной, если никакая другая транзакция чтения/записи не пересылала и не подтверждала изменения для новой версии этой записи. Транзакциям READ COMMITTED разрешается пересылать изменения, перезаписывающие подтвержденные версии более новых транзакций;

* если пересылка успешна, транзакция устанавливает «замок» на эту запись. Другие транзакции могут читать последнюю подтвержденную версию, однако ни одна пересылка изменения или удаления этой строки не будет успешной.

Блокировка на уровне таблицы

Транзакция может быть сконфигурирована для блокирования всей таблицы. Существует два приемлемых способа сделать это в DSQL: установив уровень изоляции транзакции в SNAPSHOT TABLE STABILITY (известный также как согласованный режим, поддерживаемый повторяемым чтением, repeatable read) или с помощью резервирования таблицы. Следует подчеркнуть, что такие настройки нужны в случае, когда требуются приоритетные условия. Они не рекомендуются для ежедневного использования в Firebird.

Неприемлемый способ установления блокировки на уровне таблицы (Firebird 1.5 и выше) — применение пессимистической блокировки на уровне оператора, которая действует на всю таблицу. Оператор подобный следующему делает это:

SELECT * FROM ATABLE

FOR UPDATE WITH LOCK;

Строго говоря, это не является вопросом конфигурирования транзакции. Тем не менее конфигурирование транзакции, которая владеет наборами, найденными с этой явной пессимистической блокировкой, является важным. Вопросы пессимистической блокировки обсуждаются в главе 27.

Добавление

Не существует «дельт» или блокировок для добавления. Если другая транзакция перед этим не выполняла добавления в условиях блокировки на уровне таблицы, добавление всегда будет успешным, если оно не нарушает каких-либо ограничений или проверок достоверности.

«Старение» и статистика транзакций

Когда клиентский процесс передает дескриптор транзакции, он получает уникальный внутренний идентификатор для транзакции и сохраняет его в инвентарной странице транзакции (Transaction Inventory Page, TIP).

Идентификатор и возраст транзакции

Идентификатор транзакции является 32-битовым целым, которое генерируется с единичным приращением. Новая или только восстановленная база данных начинает Серию идентификаторов с единицы. Возраст транзакции определяется ее идентификатором: самая старая имеет наименьший идентификатор.

Идентификаторы транзакций и ассоциированные с ними состояния данных сохраняются в инвентарных страницах транзакций. На заголовочной странице базы данных система учета поддерживает набор полей, содержащих идентификаторы транзакций, интересующих эту систему, а именно старейшую заинтересованную транзакцию (Oldest Interesting Transaction, OIT), старейшую активную транзакцию (Oldest Active Transaction, OAT) и число, используемое в следующей транзакции. «Мгновенный снимок» идентификатора транзакции также записывается каждый раз, когда увеличивается OAT — обычно тот же самый идентификатор, что и OAT, или близкий к нему.

Получение идентификатора транзакции

Firebird 1.5 и более поздние версии имеют контекстную переменную CURRENT? TRANSACTION, которая возвращает идентификатор данной транзакции. Она может использоваться в SQL в любом выражении. Например, для сохранения идентификатора транзакции в таблице протокола вы можете использовать следующее:

INSERT INTO BOOK_OF_LIFE

(TID, COMMENT, SIGNATURE) VALUES

(CURRENT_TRANSACTION,

‘This has been a great day for transactions’, CUERENT_USER) ;

Важно помнить, что идентификаторы транзакций являются циклическими. Поскольку нумерация сбрасывается после каждого восстановления (restore) базы данных, идентификаторы транзакций не должны использоваться для первичных ключей или ограничений уникальности.

Переполнение идентификатора транзакции

Как было сказано, идентификатор транзакции является 32-битовым целым. Если последовательность идентификаторов превысит лимит в 4 Гбайт и начнется новый отсчет, то могут произойти неприятные вещи. Когда завершится последняя транзакция, системная транзакция перестанет работать, и изменение метаданных будет невозможным. Сборка мусора прекратится. Транзакции пользователя не станут запускаться.

При 100 транзакциях в секунду это займет 1 год, 4 месяца, 11 дней, 2 часа и приблизительно 30 минут^[90].

Резервное копирование и восстановление базы данных восстанавливает идентификаторы транзакций. До последнего времени заброшенная база данных могла получить другие травмы до того, как будет исчерпана последовательность идентификаторов транзакций. Теперь при больших размерах страниц, больших объемах дисков и уменьшении необходимости отслеживать размер файлов базы, данных риск переполнения последовательности идентификаторов транзакций более вероятен.

«Заинтересованные транзакции»

Подпрограммы учета транзакций сервера и клиента используют идентификаторы транзакций для отслеживания состояния транзакций. Служебные подпрограммы используют возраст транзакций для решения вопроса, какие старые версии записей являются «интересными», а какие нет. Неинтересные транзакции могут быть отмечены для удаления. Сервер остается «заинтересованным» в каждой транзакции, которая не была жестко подтверждена с помощью оператора COMMIT.

Активные, зависшие (limbo), отмененные и «умершие» транзакции все являются интересными. Транзакции, которые были подтверждены с использованием оператора COMMIT WITH RETAIN (мягкое подтверждение или CommitRetaining), остаются активными, пока не будут подтверждены жестко, и поэтому являются интересными. В некоторых случаях интересные транзакции могут стать «застрявшими» и станут тормозить работу.

Заброшенные, застрявшие транзакции станут источником серьезного ухудшения производительности. Застрявшие OIT (старейшие заинтересованные транзакции) приведут к росту количества инвентарных страниц транзакций. Сервер поддерживает рабочую таблицу транзакций в виде битовой маски, хранящейся в инвентарных страницах транзакций. Таблица копируется и записывается в базу данных при старте каждой транзакции^[91]. Когда она непомерно раздуется от застрявших транзакций, она

будет использовать гораздо больше ресурсов памяти, и память станет фрагментированной от постоянного выделения ресурсов.

Старейшая заинтересованная транзакция

OIT является транзакцией с наименьшим номером в инвентарной странице транзакций, которая находится в неподтвержденном (rolled back) состоянии.

Старейшая активная транзакция

OAT- это транзакция с наименьшим номером в инвентарной странице транзакций, которая является активной. Транзакция является активной до тех пор, пока она не подтверждена жестко, не выполнен ее откат, и если она не является зависшей (limbo)^[92].

Транзакции только для чтения

Транзакция только для чтения остается активной (и в некоторой степени интересной), пока не будет подтверждена. При этом активная транзакция только для чтения, для которой рекомендуется уровень изоляции READ COMMITTED (см. главу 26), никогда не становится застрявшей и не влияет на систему обслуживания.

! ! !

ВНИМАНИЕ! Не путайте транзакцию только для чтения с транзакцией чтения/записи, которая выполняет передачу выходного набора пользовательскому интерфейсу от оператора SELECT. Даже если приложение делает выходной набор набором только для чтения, оператор SELECT внутри транзакции чтения/записи может стать — и часто бывает — причиной замедления работы системы.

. ! .

Фоновая сборка мусора

Версии записей отмененных транзакций вычищаются из базы данных, когда они обнаруживаются в процессе обычной обработки данных. Как правило, если к строке обращается оператор, то любая неинтересная старая версия записи, подходящая для удаления, будет отмечена для процесса сборки мусора.

Некоторые «закоулки» базы данных могут не посещаться операторами в течение длительного времени, следовательно, нет гарантии, что все версии записей, созданные в .отмененных транзакциях, будут отмечены и в итоге удалены. До тех пор, пока остаются старые версии записей, заинтересованная транзакция должна оставаться «интересной» для сохранения состояния базы данных.

! ! !

СОВЕТ. Полное сканирование базы данных (обычно при резервном копировании) выполнит сборку мусора, но не сможет изменить состояния транзакций. Это работа для «полной» сборки мусора, выполняемой при чистке (sweep) базы данных.

. ! .

Отмененные транзакции

Транзакции в отмененном (rolled back) состоянии не включены в сборку мусора. Они остаются заинтересованными, пока чистка базы данных не отметит их как «подтвержденные» и не освободит их для сборки мусора. В системах с низким уровнем конфликтов периодическая ручная чистка базы данных может быть единственно необходимой работой.

Некоторые системы, плохо спроектированные для работы с конфликтами, демонстрируют высокий уровень откатов транзакций и имеют тенденцию накапливать ‘заинтересованные’ транзакции быстрее, чем с ними могут справиться автоматические процедуры обслуживания базы данных. В подобных системах должна часто выполняться ручная чистка, если складывается впечатление, что автоматическая чистка не работает надлежащим образом.

«Мертвые» транзакции

Транзакции считаются «мертвыми», если они находятся в активном состоянии, но не существует связанного с ними контекста соединения. Обычно транзакции «умирают» в клиентских приложениях, которые не заботятся об их завершении перед отключением от базы данных. Умершие транзакции также являются частью обломков, оставленных после краха клиентских приложений или поломки сетевых соединений.

Сервер не может определить разницы между действительно активными транзакциями и умершими. Пока тайм-аут ожидания соединения работает, и регулярная сборка мусора своевременно убирает ненужные транзакции, умершие транзакции не создают проблем. При срабатывании тайм-аута соединения выполнится их откат, и в итоге этот мусор будет убран.

Частое большое накопление умерших транзакций может стать проблемой. Поскольку они не являются отмененными, слишком многие из них остаются заинтересованными на чрезмерно большой срок. В системе, где поведение пользователя, частые аварии программ, отключение питания или сетевые ошибки генерируют огромное количество умерших транзакций, мусор от умерших транзакций становится большой проблемой.

Зависшие транзакции

Зависшие транзакции (limbo transactions), подробно обсуждаемые в главе 26, появляются в результате сбоя двухфазной операции COMMIT для нескольких баз данных. Система распознает их как особый случай, требующий вмешательства человека, поскольку сам сервер не может определить, будет ли их подтверждение или откат влиять на согласованность данных в разных базах данных.

Единственный способ разрешить зависшие транзакции — это запустить для базы данных инструмент gfix с соответствующими переключателями для достижения желаемого результата. Утилита изменяет состояние транзакции либо на «подтвержденное», либо на «отмененное». С этого момента с ней осуществляется работа, как и с любой другой подтвержденной или отмененной транзакцией.

OIT и OAT должны постоянно изменяться

Совет «OIT и OAT должны постоянно изменяться» является ключевой фразой для решения всех проблем, связанных с производительностью базы данных. Время, потраченное на изучение цикла жизни транзакций в многоверсионной архитектуре Firebird, будет одним из лучших ваших вложений в дальнейшую работу с Firebird другими базами данных с открытыми текстами^[93].

Для начала понимания взаимодействия между клиентскими процессами, которые «владеют» транзакциями, с одной стороны, и учетом транзакций, выполняемым в базе данных, с другой, будет полезным познакомиться с механизмом взаимодействия сервера и транзакций.

Образ состояния транзакции

Внутренний образ состояния транзакции (Transaction State Bitmap, TSB) является таблицей, содержащей идентификаторы транзакций и их состояние, поддерживаемой сервером и инициализируемой при начальном подключении к базе данных. В логических терминах TSB содержит каждую транзакцию, найденную в инвентарных страницах транзакций, которая новее, чем OIT. Пока существуют подключения к базе данных, серверный процесс поддерживает TSB динамически, добавляя новые идентификаторы транзакций, изменяя состояние и удаляя идентификаторы, которые становятся неинтересными (т. е. будут подтверждены). Сервер записывает изменения в инвентарные страницы транзакций без повторного их чтения с диска.

На рис. 25.2 иллюстрируются эти шаги. Каждый раз, когда сервер обрабатывает запрос для транзакции, он читает заголовочную страницу базы данных, чтобы получить идентификатор для следующей транзакции. Изменяется TSB, и изменения записываются в инвентарные страницы базы данных.

«Движение вперед OIT (И/ИЛИ OAT)» — это термин Firebird, обозначающий увеличение значений OIT и OAT

В заголовочной странице базы данных, когда подтверждающиеся более старые транзакции исключаются из TSB, а новые транзакции, в свою очередь, становятся «старейшими». Обновление заголовочной страницы базы данных последними значениями OIT, OAT и следующей транзакции являются частью такой динамической экологии.

Если новая транзакция является транзакцией SNAPSHOT, она будет иметь свою собственную копию TSB для поддержания согласованного вида состояния базы данных, каким он был при ее старте. Транзакция READ COMMITTED всегда обращается к самому последнему «глобальному» TSB для получения доступа к версиям, подтвержденным после ее старта.

Рис. 25.2. Взаимодействие процесса клиент-сервер с TSB

Условия для изменения OIT и OAT

Каждый раз, когда сервер стартует другую транзакцию, он проверяет состояние идентификаторов транзакций, которые он хранит в TSB, удаляя те, чье состояние было изменено на «подтвержденное», и заново вычисляет значения OIT и OAT. Он сравнивает их с хранимыми значениями в странице базы данных и при необходимости включает их в данные, сопровождающие запись в заголовок базы данных идентификатора новой «следующей транзакции».

Значение OAT будет увеличиваться, если транзакции будут достаточно короткими, чтобы предохранять активные транзакции и мусор от самых новых транзакций — от нагромождения, OIT будет увеличиваться, пока клиентские процессы подтверждают свою работу в большей степени, нежели отменяют их или теряют в результате аварий. При этих условиях производительность базы данных будет хорошей.

Застрявшая OAT хуже, чем застрявшая OIT. В системе с хорошей производительностью разница между OAT и самой новой транзакцией должна приблизительно равняться

количеству запущенных клиентских процессов, умноженному на среднее количество выполняющихся транзакций в каждом процессе. Выполняйте чистку базы данных во внерабочее время или используйте автоматическую чистку или оба варианта.

В главе 27 вы найдете несколько стратегий клиентских приложений для оптимизации OIT и OAT.

«Зазор»

«Зазор» — еще одна часть Firebird. Он означает разницу между OIT и OAT. Зазор будет небольшим в сравнении с общим количеством транзакций или, в идеале, нулем. При этих условиях разумно предположить, что не существует подвешенных транзакций, что привело бы к раздуванию TSB и большому разрастанию инвентарных страниц транзакций.

Собственно сам зазор не ухудшает производительность. Зазор является индикатором большого объема накладных расходов, добавляемых системой управления транзакциями к обработке базы данных — чрезмерное использование и фрагментация памяти, избыточное количество читаемых страниц в процессе поиска и выделяемых страниц в процессе изменения и добавления данных. Решение и устранение проблем ухудшения производительности заключается в уменьшении зазора.

Чистка в сравнении со сборкой мусора

Сборка мусора (Garbage Collection, GB) — это постоянный фоновый процесс, который является функцией нормальной деятельности по поиску записей и проверке версий записей, которая выполняется для каждой транзакции. Когда обнаруживается устаревшая версия записи с идентификатором меньшим, чем OAT, происходит одно из двух:

* для Классического сервера устаревшие версии записей удаляются немедленно. Это называется кооперативной сборкой мусора, потому что каждая транзакция и каждый экземпляр сервера участвуют в чистке мусора, опережая все другие;

* для Суперсервера устаревшие версии записей помечаются во внутреннем списке удаляемых элементов для потока сборки мусора. Когда поток сборки мусора «просыпается», он будет работать с элементами в этом списке, изменяя его.

Чистка (sweep) также выполняет эту задачу, но в отличие от сборки мусора она может иметь дело с одной категорией заинтересованных транзакций: с теми, которые имеют состояние «отмененные» (rolled back). Она может также удалить «остатки» удаленных записей и освободить память для повторного использования.

Зазор является важным для автоматической чистки, потому что установленный для базы данных интервал чистки (sweeping interval) управляет максимальной величиной зазора, при достижении которого стартует процесс чистки^[94]. Автоматическая чистка выполняется редко или никогда не выполняется для некоторых баз данных, потому что зазор не достигает порогового значения.

По умолчанию каждая база данных создается с интервалом чистки (максимальной величиной зазора) в 20 000. При необходимости эта величина может быть увеличена или уменьшена, или же чистка совсем может быть отключена при установке величины интервала в 0.

В системе, где зазор всегда меньше интервала чистки, не является справедливым, что для базы данных никогда не требуется чистка. Все базы данных должны вычищаться — это вопрос управления базами данных человеком, будут ли они чиститься автоматически, вручную с использованием gfix или обоими способами. Думайте об автоматической чистке как о системе стабильного функционирования, а не как о заменителе удобного управления базой данных.

Статистика транзакций

В Firebird есть несколько полезных утилит для получения сведений о том, насколько хорошо ваша база данных управляет зазором между OIT и OAT. Их вы можете также использовать для просмотра значений в заголовочной странице базы данных.

gstat

Инструмент командной строки gstat, используемый с переключателем -header, показывает различную статистическую информацию базы данных, включая текущее значение идентификатора транзакции для OIT, OAT и для следующей новой транзакции. Для использования gstat соединитесь с базой данных как пользователь SYSDBA из командной строки на главной машине и перейдите в каталог bin Firebird. Наберите следующий текст в Windows:

gstat -h <путь-к-базе-данных> -user sysdba -password masterkey

Наберите в POSIX:

./gstat -h <путь-к-базе-данных> -user sysdba -password masterkey

Вот фрагмент выходных данных:

Oldest transaction 10075

Oldest active 100152

Oldest snapshot 100152

Next transaction 100153

Терминология в этом отчете может вызвать удивление. При просмотре выхода gstat имейте в виду, что:

* Oldest transaction — это OIT;

* Oldest active — очевидно, OAT;

* oldest snapshot- обычно то же, что и OAT- строка будет выведена, когда OAT продвигается далее. Это фактический идентификатор транзакции, рассматриваемый сборщиком мусора как сигнал существования мусора, который может быть обработан^[95].

isql

Вы можете получить похожий вид статистики из заголовка базы данных в сессии isql при использовании команды SHOW DATABASE.

Многие инструменты администратора Firebird сторонних разработчиков создают эквивалентные отчеты.

Что может рассказать вам статистика

Сборка мусора всегда будет выполняться над устаревшими версиями записей, не трогая заинтересованные транзакции. При этом OLDEST SNAPSHOT отмечает границы, на которых сборщик мусора останавливает просмотр подтвержденных транзакций. Любой мусор с такого номера транзакции и выше не будет обрабатываться.

Если зазор между OAT и NEXT TRANSACTION определяет гораздо большее количество транзакций, чем подсчитываемое количество подключенных пользователей и их задач, вы можете быть уверенными, что большое количество мусора не будет обрабатываться сборщиком мусора. Если этот зазор будет увеличиваться, работа с базой данных будет все больше и больше замедляться. Серверы будут выдавать ошибку «Out of memory» (недостаточно памяти) или просто будут аварийно завершаться, потому что TSB расходует большой объем памяти или приводит к тому, что сервисы управления системной памятью используют слишком сильную фрагментации памяти. Дешевые серверы — особенно те, которые нагружены предоставлением дополнительных сервисов- даже могут не получить достаточно ресурсов для записи сообщения в протокол.

Если вам кажется, что зазоры между OIT и OAT или между OAT и NEXT TRANSACTION приводят к проблемам в вашей системе, вы можете многое узнать о воздействиях чистки базы данных и улучшения ваших приложений, если сохраните протоколы статистики.

! ! !

СОВЕТ. Для получения текстовых файлов простой статистики просто перенаправьте выход утилиты gstat -h в текстовый файл в соответствии с правилами вашей командной строки. В утилите isql используйте команду output <имя файла> для перенаправления результатов выполнения команды SHOW DATABASE.

. ! .

Пора дальше

Драйверы, которые скрывают от разработчика приложений явное управление транзакциями и нивелируют разницу между различными реализациями поставщиков SQL, редко способствуют высокой производительности пользовательских приложений, а также хорошему здоровью и гигиене базы данных. В следующей главе рассматриваются различные комбинации параметров, доступные для конфигурирования транзакций, а также стратегии, которые вы можете использовать для подгонки транзакций к каждой задаче.

ГЛАВА 26. Конфигурирование транзакций.

Транзакция является «оберткой» вокруг любого фрагмента работы, влияющего на состояние базы данных или более чем одной базы данных. Пользовательский процесс запускает транзакцию и тот же самый пользовательский процесс завершает ее. Поскольку пользовательские процессы могут иметь различные вид и размер, любая транзакция является конфигурируемой. Обязательные и дополнительные свойства транзакции являются важной частью любого контекста транзакции.

Параллельность

Термин параллельность (concurrency) относится к тому состоянию, в котором две или более задач выполняются внутри одной и той же базы данных в одно и то же время. О базе данных при этих условиях говорят, что она поддерживает параллельные задачи. Процесс, владеющий транзакцией, внутри этой транзакции способен выполнять любые операции, которые:

* будут согласованными в текущем представлении базы данных;

* при подтверждении не будут влиять на согласованность любых других текущих представлений базы данных для активных транзакций.

Каждая транзакция конфигурируется с помощью группы параметров, которые позволяют клиентскому процессу абсолютно точно прогнозировать поведение сервера базы данных, когда он обнаружит потенциальную несогласованность. Интерпретация сервером понятия «согласованности» управляется конфигурацией транзакции. Конфигурация, в свою очередь, управляется клиентским приложением.

Факторы, влияющие на параллельность

Четырьмя параметрами конфигурации, влияющими на параллельность, являются:

* уровень изоляции;

* способ разрешения блокировок;

* способ доступа;

* резервирование таблиц.

На одном из уровней изоляции (READ COMMITTED) также рассматриваются текущие состояния версий записей.

Уровень изоляции

Firebird предоставляет три уровня изоляции транзакций для определения «глубины» согласованности требований транзакции. В одном крайнем случае транзакция может получить исключительный доступ по записи ко всей таблице, в то время как в другом крайнем случае неподтвержденная транзакция получает доступ к любым внешним изменениям состояния базы данных. Никакая транзакция в Firebird не сможет видеть неподтвержденные изменения данных от других транзакций.

В Firebird уровень изоляции может быть:

* READ COMMITTED:

• RECORD_VERSION;

• NO RECORD_VERSION;

* SNAPSHOT;

* SNAPSHOT TABLE STABILITY.

Стандартные уровни изоляции

Стандарт SQL по изоляции транзакций «симпатизирует» механизму двухфазной блокировки, которую использует большинство реляционных СУБД для реализации изоляции. Это является его отличительной чертой по сравнению с большинством других стандартов. Он определяет изоляцию не столько в теоретических терминах, сколько в терминах феноменов, допускаемых каждым уровнем (или запрещаемых им). Феноменами, с которыми имеет дело стандарт, являются:

* «грязное» чтение (Dirty read): появляется, если транзакция способна читать неподтвержденные (ожидающие завершения) изменения, выполненные другими транзакциями;

* неповторяемое чтение (Non-repeatable read): появляется, если последующие чтения набора строк в рамках этой же транзакции могут отличаться от того, что было прочитано транзакцией в начале ее работы;

* фантомные строки (Phantom rows): появляется, если последующий набор строк, прочитанный транзакцией, отличается от набора, который был прочитан в начале работы транзакции. Фантомные явления появляются, если при последующем чтении появляются новые добавленные строки и/или исчезают удаленные строки, которые были подтверждены с момента первого чтения.

В табл. 26.1 показаны определяемые в стандарте четыре уровня изоляции с явлениями, которые управляют их определениями.

READ UNCOMMITTED вовсе не поддерживается в Firebird, READ COMMITTED соответствует стандарту. На двух следующих уровнях этого уровня изоляции природа многоверсионной архитектуры превалирует над ограничениями двухфазной блокировки, предлагаемой стандартом. Отображение указанных в стандарте уровней REPEATABLE READ и SERIALIZABLE невозможно.

Таблица 26.1. Уровни изоляции и управление феноменами в стандарте SQL

Уровень изоляции	«Грязное»чтение	Неповторяемое чтение	Фантомы
READ UNCOMMITTED	Допустимо	Допустимо	Допустимо
READ COMMITTED	Недопустимо	Допустимо	Допустимо
REPEATABLE READ	Недопустимо	Недопустимо	Допустимо
SERIALIZABLE	Недопустимо	Недопустимо	Недопустимо

READ COMMITTED

Самым низким уровнем изоляции является READ COMMITTED. Только на этом уровне изоляции вид состояния базы данных, измененного в процессе выполнения транзакции, изменяется каждый раз, когда подтверждаются версии записей. Вновь подтвержденная версия записи заменяет ту версию, которая была видна при старте транзакции. Подтвержденные добавления, выполненные после старта транзакции, становятся видимыми для нее.

Уровень изоляции READ COMMITTED обеспечивает неповторяемое чтение и не избавляет от феномена фантомных строк. Это наиболее полезный уровень для операций реального времени над большим объемом данных, т. к. сокращается количество конфликтов данных, однако он не является подходящим для задач, которым нужен воспроизводимый вид.

Поскольку уровень изоляции READ COMMITTED имеет скоротечную природу, то транзакция (именно этого уровня) может быть сконфигурирована в соответствии с потребностями реагирования на подтверждение изменений и наличие ожидающих завершения изменений других транзакций.

* При установке RECORD_VERSION (флаг по умолчанию) сервер позволяет транзакции читать самую последнюю подтвержденную версию записи. Если транзакция имеет режим READ WRITE (чтение/запись), то она будет способна перезаписывать самую последнюю подтвержденную версию записи, если ее идентификатор (TID) более поздний, чем идентификатор транзакции, подтвердившей самую последнюю версию записи.

* При установке NO_RECORD_VERSION сервер эффективно имитирует поведение систем, которые используют двухфазную блокировку для управления параллельностью. Он блокирует для текущей транзакции чтение строки, если для нее существует изменение, ожидающее завершения. Разрешение ситуации зависит от установки разрешения блокировки.

• При задании WAIT транзакция будет ждать, когда другая транзакция либо подтвердит, либо отменит свои изменения. Эти изменения затем станут доступными, если другая транзакция их отменит или если идентификатор транзакции более поздний, чем идентификатор другой транзакции. Транзакция будет завершена аварийно по конфликту блокировки, если идентификатор другой транзакции будет более поздним.

При задании NOWAIT транзакция немедленно получит сообщение о конфликте блокировки.

! ! !

ПРИМЕЧАНИЕ. Транзакция READ COMMITTED может видеть все последние подтвержденные версии, которые позволяют читать установки этой транзакции, что подходит для операций добавления, изменения, удаления и выполнения. При этом любые выходные наборы, полученные в транзакции по оператору SELECT, должны получать измененный вид базы данных.

. ! .

SNAPSHOT (параллельность)

«Средним» уровнем изоляции является SNAPSHOT, альтернативно называемый Repeatabie Read (повторяемое чтение) или concurrency (параллельность). При этом изоляция SNAPSHOT В Firebird не является в точности соответствующей уровню Repeatabie Read, как он определен в стандарте. Он изолирует вид базы данных для транзакции изменениями на уровне строк только для существующих строк. При этом, поскольку по своей природе многоверсионная архитектура полностью изолирует транзакции SNAPSHOT от новых строк, подтвержденных другими транзакциями, не предоставляя транзакциям SNAPSHOT доступ к глобальному образу состояния транзакций (TSB, см. главу 25), транзакции SNAPSHOT не могут видеть фантомные строки. Следовательно, транзакции SNAPSHOT В Firebird предоставляют более глубокий уровень изоляции, чем REPEATABLE READ В SQL.

Пока SNAPSHOT еще не идентичен SERIALIZABLE, потому что другие транзакции могут изменять и удалять строки, которые находятся в зоне видимости транзакции SERIALIZABLE.

Транзакция гарантирует неизменный вид базы данных, который до завершения транзакции не будет зависеть от любых подтвержденных изменений в других транзакциях. Такой уровень полезен для «исторических» задач, таких как формирование отчетов или экспорт данных, которые могут оказаться ошибочными, если не будут выполняться с воспроизводимым видом данных.

SNAPSHOT является уровнем изоляции по умолчанию для инструмента обработки запросов isql, а также для многих компонентов и драйверов интерфейса.

SNAPSHOT TABLE STABILITY (согласованность)

Самым «глубоким» уровнем изоляции является SNAPSHOT TABLE STABILITY, альтернативно называемый consistency, потому что он гарантирует получение данных в неизменном состоянии, который останется внешне согласованным в пределах базы данных, пока продолжается транзакция. Транзакции чтения/записи не могут даже читать таблицы, которые блокируются транзакцией с таким уровнем изоляции.

Блокировка на уровне таблицы, создаваемая этим уровнем изоляции, включает в себя все таблицы, к которым осуществляет доступ транзакция, включая те, которые связаны ссылочными ограничениями.

Этот уровень устанавливает агрессивное расширение, которое гарантирует сериализацию в строгом смысле, т. е. никакая другая транзакция не может добавлять или удалять — вообще изменять — строки в используемых таблицах, если любая транзакция получает дескриптор с этим уровнем изоляции. Наоборот, транзакция TABLE STABILITY не сможет получить дескриптор, если какая-нибудь транзакция чтения/записи в настоящий момент читает любую таблицу, которая находится в зоне видимости этой транзакции. В терминах стандарта это не обязательно, поскольку изоляция SNAPSHOT уже защищает транзакции от всех трех феноменов, управляемых уровнем SERIALIZABLE в стандарте SQL.

Транзакция consistency еще называется блокирующей транзакцией, потому что она блокирует доступ любых других транзакций чтения/записи к любым записям, к которым эта транзакция обращается, и к любым записям, зависящим от этих записей.

! ! !

ВНИМАНИЕ! Поскольку этот уровень потенциально блокирует часть базы данных для других пользователей, которым нужно выполнять изменения, SNAPSHOT TABLE STABILITY должен использоваться осторожно. Внимательно следите за размером применяемых наборов, воздействием на соединения, зависимые таблицы и особенно за длительностью такой транзакции.

. ! .

Способ доступа

Способ доступа может быть READ WRITE (чтение/запись) или READ ONLY (только чтение). Транзакция READ WRITE может выбирать, добавлять, изменять и удалять данные. Транзакция READ ONLY может только выбирать данные.

Способом доступа по умолчанию является READ WRITE.

! ! !

СОВЕТ. Одним из преимуществ транзакции READ ONLY является ее способность выбирать записи для пользовательского интерфейса без использования большого объема ресурсов на сервере. Убедитесь, что ваши транзакции только для чтения сконфигурированы с уровнем изоляции READ COMMITTED, чтобы гарантировать, что сборка мусора на сервере будет выполняться, минуя эту транзакцию.

. ! .

Способ разрешения блокировок («Режим блокировок»)

Способ разрешения блокировок определяет поведение транзакции в случае, когда она пытается отправить изменение, которое конфликтует с изменением, уже отправленным другой транзакцией. Значениями являются WAIT и NOWAIT.

WAIT

WAIT (по умолчанию) приводит к тому, что транзакция будет ожидать, пока заблокированные строки ожидающей завершения транзакцией не будут освобождены прежде, чем она станет определять, может ли эта транзакция их изменять. Если другая транзакция отправит более новую версию записи, то ожидающая транзакция выдаст сообщение, что возник конфликт блокировки.

WAIT чаще всего не является предпочтительным способом блокировки для интерактивных систем с большим объемом данных, потому что он может замедлять работу пользователей и при некоторых условиях может приводить к тупикам (см. разд. «Что такое взаимная блокировка?»).

Использование WAIT бессмысленно в изоляции SNAPSHOT. Если только блокирующая транзакция в итоге не выполнит откат- наименее вероятный сценарий- результатом ожидания, естественно, будет конфликт блокировки. В транзакции READ COMMITTED вероятность того, что результатом ожидания будет конфликт блокировки, весьма мала.

Это не означает, что вариант WAIT не будет полезным при некоторых условиях. Если обработчик исключений в клиентском приложении обрабатывает конфликты, постоянно повторяя обращение без пауз, то перегрузка системы, вызванная этими постоянными повторениями и отказами, будет большим злом, чем, если бы было указано WAIT, особенно если блокирующая транзакция требует много времени для завершения. В сравнении с этим WAIT может приводить только к одному исключению, обрабатываемому с помощью одного отката.

Когда вероятность столкновений транзакций высока, но транзакции короткие, WAIT является предпочтительным, потому что гарантирует, что ожидающие запросы будут обрабатываться в последовательности FIFO (First In First Out, первый пришел — первый ушел). При этом в пользовательских системах, где быстрые операции не гарантированы, транзакции WAIT противопоказаны, потому что потенциально задерживают сборку мусора.

NO WAIT

В транзакции NO WAIT сервер немедленно сообщит клиенту об обнаружении новой неподтвержденной версии строки, которую пытается изменять транзакция. В разумно нагруженных многопользовательских системах NO WAIT часто является предпочтительным для устранения риска перегрузки системы ожидающими транзакциями.

По эмпирическому правилу для транзакций SNAPSHOT производительность будет выше, а пользовательские интерфейсы более оперативными, если клиентское приложение выберет NO WAIT и будет обрабатывать конфликты блокировок, используя откат, синхронизированный повтор операции или другие подходящие техники.

Резервирование таблиц

Firebird поддерживает режим блокировки таблиц для обеспечения полной блокировки одной или более таблиц в процессе выполнения транзакции. Необязательное предложение RESERVING <список таблиц> запрашивает немедленную полную блокировку всех подтвержденных строк указанных таблиц, предоставляя транзакции исключительный доступ за счет любых транзакций, конкурирующих с этой транзакцией.

В отличие от обычной тактики

блокирования резервирование блокирует все строки пессимистически — оно действует с момента запуска транзакции, а не ожидает момента, когда потребуется блокировка индивидуальной строки.

Резервирование таблиц имеет три основные цели.

* Обеспечение блокировки таблиц на момент начала транзакции, а не в то время, когда к ним обращается первый оператор, что происходит в случае изоляции TABLE STABILITY, используемом для блокировки на уровне таблиц. Режим разрешения блокировки (WAIT/NOWAIT) применяется во время запроса транзакции, когда возникает конфликт с другими транзакциями, имеющими изменения данных, ожидающих завершения. В этом случае результатом будет обработка запроса при WAIT и отказ в обработке при NOWAIT. Такая возможность резервирования таблиц важна, потому что резко сокращает вероятность взаимных блокировок.

* Обеспечение зависимой блокировки (т. е. блокировки таблиц, к которым могут происходить обращения в триггерах и в ограничениях целостности). Зависимая блокировка не является нормальной в Firebird. При этом она устраняет конфликты изменения, появляющиеся при конфликтах непрямых зависимостей.

* Увеличение приоритета транзакции в отношении одной или более таблиц, с которыми она будет работать. Например, транзакция SNAPSHOT, которой нужен исключительный доступ по записи ко всем строкам какой-либо таблицы, может ее зарезервировать, оставляя обычным приоритет по отношению к строкам других таблиц. Это менее агрессивный способ применения блокировки на уровне таблицы, чем альтернативный, использующий уровень изоляции TABLE STABILITY.

В транзакции вы можете резервировать более одной таблицы.

Использование резервирования таблиц

Использование резервирования таблиц с уровнями изоляции SNAPSHOT и READ COMMITTED является более предпочтительным, чем с SNAPSHOT TABLE STABILITY, когда требуется блокировка на уровне таблицы. Резервирование таблиц является менее агрессивным и более гибким способом предварительной блокировки таблиц. Он доступен для использования с любым уровнем изоляции. При этом его использование с SNAPSHOT TABLE STABILITY не рекомендуется, поскольку он не имеет эффекта при ограничениях доступа к таблицам, к которым транзакции может понадобиться доступ и которые находятся за пределами предложения RESERVING.

Преимущественная блокировка таблиц не является средством для ежедневного использования, но она может быть полезной в таких задачах, как предварительная оценка отчетности или получение отчета по «замороженным запасам» перед инвентаризацией.

Параметры резервирования таблиц

Каждое резервирование таблиц может быть сконфигурировано с помощью различных атрибутов для задания того, как должны трактоваться разные транзакции при запросах доступа к зарезервированным таблицам.

! ! !

ПРИМЕЧАНИЕ. Транзакция SNAPSHOT TABLE STABILITY не может получить доступ ни к какой таблице, зарезервированной с помощью средства резервирования таблиц.

. ! .

Вариантами выбора являются:

[PROTECTED | SHARED] {READ | WRITE}

Атрибут PROTECTED предоставляет транзакции исключительный доступ к таблице по чтению и позволяет другим транзакциям с уровнями изоляции SNAPSHOT и READ COMMITTED читать строки. Запись ограничивается одним или двумя модификаторами:

* PROTECTED WRITE позволяет текущей транзакции писать в таблицу и блокирует запись другими транзакциями;

* PROTECTED READ запрещает запись в таблицу для любой транзакции, включая текущую.

Атрибут SHARED позволяет любой транзакции SNAPSHOT или READ COMMITTED читать из таблицы и предоставляет два режима для параллельных изменений другими транзакциями:

* SHARED WRITE любой транзакции чтения/записи SNAPSHOT или транзакции чтения/записи READ COMMITTED изменять строки в наборе, пока никакая транзакция не имеет или не запросит исключительного доступа по записи;

* SHARED READ является наиболее либеральным условием резервирования. Этот режим позволяет любой другой транзакции чтения/записи изменять таблицу.

Итоги

Любая другая транзакция может читать таблицу, зарезервированную текущей транзакцией, причем не существует никаких способов сконфигурировать транзакцию так, чтобы предоставить ей исключительные права на запись для этой таблицы (т. е. все могут читать, если они были сконфигурированы только для чтения и не имеют никаких преимущественных прав на запись). Следующие условия всегда будут блокировать другую транзакцию на чтение из таблицы, зарезервированной текущей транзакцией:

* другая транзакция имеет уровень изоляции SNAPSHOT TABLE STABILITY;

* другая транзакция сконфигурирована на резервирование этой таблицы в режиме PROTECTED WRITE (хотя она может читать эту таблицу, если текущая транзакция зарезервировала ее в режиме SHARED READ);

* другая транзакция собирается зарезервировать эту таблицу в режиме SHARED WRITE, а текущая транзакция зарезервировала ее в режиме PROTECTED READ или PROTECTED WRITE.

В случае если это все еще вам непонятно, посмотрите на рис. 26.1, где некоторые сконфигурированные транзакции сами все расскажут.

Рис. 26.1. Конфигурирование резервирования таблиц

Версии записей

Когда запрос на изменение успешно отправлен на сервер, Firebird создает и записывает на диск ссылку, связывающую оригинальный образ строки, видимый в транзакции — иногда это называется дельтой, — с новой версией строки, содержащей изменения запроса. Оригинальный и новый образы строки называются версиями записи. Когда новая версия записи создается в транзакции более новой, чем транзакция, которая создала «живую» версию, другие транзакции не будут иметь возможности изменять или удалять оригинал, если только транзакция, создавшая новую версию, не выполнит откат. Процесс создания версий подробно описан в главе 25.

Пока транзакция, в конце концов, не подтвердит изменения, она не касается «живой» версии. В своем собственном контексте она трактует отправленную версию, как если бы она была самой последней подтвержденной версией. Тем временем другие транзакции продолжают «видеть» самую последнюю подтвержденную версию. В случае «мгновенного снимка» базы данных (snapshot) в транзакциях, которые были запущены до нашей транзакции, последняя подтвержденная версия записи, которую они видят, может быть более старой, чем та, которую видит наша транзакция и другие транзакции, либо ранее запущенные, либо имеющие уровень изоляции READ COMMITTED.

Зависимые строки

Если на таблицу, изменение в которой было отправлено на сервер, ссылаются внешние ключи других таблиц, сервер создает версии строк в этих таблицах, которые «принадлежат» измененной строке^[96]. Эти зависимые строки, равно как и другие строки других таблиц, зависящие от них через внешние ключи, также становятся недоступными другим транзакциям для изменения, пока выполняется наша транзакция.

Блокировки и конфликты блокировок

В Firebird блокировки управляются относительным возрастом транзакций, а записи управляются системой поддержки версий. Все блокировки применяются на уровне строки, за исключением тех случаев, когда транзакция оперирует на уровне изоляции SNAPSHOT TABLE STABILITY или когда используется резервирование таблицы, которое блокирует доступ по записи.

Время действия

Время действия блокировки строки при обычной активности чтения/записи является оптимистическим — не выполняется никакая блокировка никаких строк до того момента, когда она действительно нужна. Пока изменения строки не отправлены на сервер, строка свободна для «получения» любой транзакцией чтения/записи.

Пессимистическая блокировка

Пессимистическая, или предварительная, блокировка может быть применена для наборов строк или для целых таблиц. Режимы блокировки таблиц уже были описаны (см. разд. «Резервирование таблиц» и «SNAPSHOT TABLE STABILITY (согласованность)»).

Пессимистическая блокировка на уровне строки и на уровне набора является режимом, при котором требование по резервированию строки или небольшого набора выполняется до фактической пересылки изменения или удаления.

Явная блокировка

Возможность осуществлять явную пессимистическую блокировку строки была добавлена в синтаксис SQL-оператора SELECT в Firebird 1.5. Блокировка ограничена «внешним уровнем» операторов SELECT, которые возвращают выходные наборы или определяют курсоры. Она не может применяться к подзапросам.

Сокращенный синтаксис запроса явной пессимистической блокировки строки:

SELECT <выходной-список>

FROM <таблица-или-процедура-или-просмотр>

[WHERE <условия-поиска>]

[GROUP BY <спецификация-группирования>]

[UNION <выражение-выбора> [ALL]]

[PLAN <выражение-плана>]

[ORDER BY <список-столбцов>]

[FOR UPDATE [OF столбец1 [, столбец2 …]] [WITH LOCK]]

Предложение FOR UPDATE, не являющееся инструкцией блокировки, указывает, что выходной набор должен передаваться клиенту по одной строке за раз, а не в виде пакета. Необязательная фраза WITH LOCK является элементом, который задает предварительную блокировку строки, как только сервер передает ее с сервера. Строки, ожидающие вывода, не блокируются.

Фиктивные изменения

Традиционным способом получения пессимистической блокировки строки в Firebird являются фиктивные изменения (dummy updates). Этот трюк позволяет использовать преимущества многоверсионной архитектуры. Клиент просто посылает на сервер для строки оператор изменения, который ничего не изменяет — он просто устанавливает значение столбца в его текущее значение, что приводит к тому, что сервер создает новую версию записи и, следовательно, блокирует для других транзакций запрос на изменение или удаление этой строки.

Условия, при которых пессимистическая блокировка может быть полезной, и технические рекомендации по ее использованию обсуждаются в главе 27.

Конфликты блокировки

Конфликт блокировки появляется, когда конкурирующие транзакции пытаются изменить или удалить одну и ту же строку в то время, когда вид состояния базы данных для этих транзакций частично перекрывается. Конфликты блокировок являются запланированным результатом уровней изоляции транзакций в Firebird и стратегии поддержания многих версий записи, защищая изменяемые данные от неконтролируемой перезаписи параллельными операциями над одними и теми же данными.

Эта стратегия работает хорошо только в случае двух условий, которые приводят к конфликтам блокировки.

* Условие 1: одна транзакция (наша транзакция) отправила на сервер изменение или удаление строки. В это время другая транзакция, стартовавшая до того, как наша транзакция заблокировала эту строку, пытается ее изменить или удалить. Другая транзакция получает конфликт блокировки и имеет два варианта выбора:

• она может отменить свою попытку и позже снова повторить ее для вновь подтвержденной версии строки;

• она может ждать, пока наша транзакция либо подтвердит, либо отменит свою работу.

* Условие 2: наша транзакция блокирует для записи целую таблицу, если имеет уровень изоляции для таблицы SNAPSHOT TABLE STABILITY или использует резервирование таблицы с помощью PROTECTED, а другая транзакция пытается изменить или удалить строку или добавить новую строку.

Предположим, что наша транзакция посылает изменение строки. Появляется другая транзакция и запрашивает изменение или удаление той же строки. При уровне изоляции SNAPSHOT и режиме WAIT другая транзакция будет ожидать, пока наша транзакция завершит свою работу путем подтверждения или отката.

Если наша транзакция подтверждает изменения, то другая транзакция получит отказ по конфликту изменения. Клиент, который запустил другую транзакцию, должен иметь обработчик исключений, который либо откатит транзакцию и заново ее запустит для повторной выдачи запроса, либо просто подтвердит транзакцию и завершит работу.

Вызов COMMIT в обработчике исключения конфликта блокировки не рекомендуется, поскольку он разрушает атомарность транзакции — некоторая работа будет завершена, некоторая нет, и впоследствии будет невозможно предсказать состояние базы данных^[97].

К сожалению, Firebird имеет тенденцию объединять все исключения блокировки и сообщает о них как «deadlock» (взаимная блокировка). Нормальные случаи, которые были описаны, не являются взаимной блокировкой.

Что такое взаимная блокировка?

Взаимная блокировка является просто сокращенным названием, заимствованным из реслинга, для условия, когда две транзакции борются за изменение строк в перекрывающихся наборах и ни одна транзакция не имеет приоритета перед другой.

Например, наша транзакция имеет изменения, ожидающие завершения, для строки x и собирается изменять строку Y в то время, как другая транзакция имеет изменения, ожидающие завершения, для строки Y и собирается изменять строку x, и обе транзакции имеют режим WAIT. Как и в реслинге, взаимная блокировка может быть разрешена, только если один из борцов не удержит руку. Одна транзакция должна выполнить откат, чтобы позволить другой подтвердить свои изменения.

Firebird предоставляет приложениям средство разрешения взаимной блокировки путем сканирования блокировок каждые несколько секунд. Он произвольно выберет одну из транзакций -взаимной блокировки и выдаст для нее исключение взаимной блокировки.

Разработчики не должны бояться сообщений о взаимной блокировке. Наоборот, имеет смысл изолировать работу многих пользователей в контекстах транзакций. Вы должны допускать наличие взаимных блокировок и эффективно их обрабатывать в вашем приложении.

Если наша транзакция выбрана для разрешения взаимной блокировки, обработчик исключения в приложении должен выполнить откат транзакции, чтобы позволить другой транзакции возобновить и завершить свою работу. Альтернатива — подтверждение транзакции в обработчике исключения — не рекомендуется, поскольку наша транзакция станет неатомарной, а другая транзакция даст сбой по конфликту блокировки.

Тупиковая ситуация

В редких случаях более двух транзакций может быть включено во взаимную блокировку при борьбе за перекрывающиеся наборы. Иногда это называется тупиковой ситуацией (программистский жаргон — deadly embrace, смертельные объятия). Сканирование блокировок выберет одну транзакцию (нашу транзакцию), ситуация будет обработана в клиентском обработчике исключений, как в предыдущем примере. При этом даже если клиент выполнит откат нашей транзакции, те другие транзакции все еще останутся заблокированными.

Активный тупик

Клиент может запустить новую транзакцию и повторить попытку, однако другие соперники все еще находятся в состоянии взаимной блокировки, ожидая следующего сканирования блокировок для освобождения следующего соперника с выдачей исключения блокировки. Если приложение повторяет попытку с транзакцией WAIT, он просто ждет бесконечное время, когда будет разрешена тупиковая ситуация с другими транзакциями. Про транзакцию с такими тщетными попытками повтора говорят, что она находится в активном тупике.

Короче говоря, важно в первую очередь исключить контексты транзакций, которые могут привести к тупиковой ситуации. В качестве дополнительной защиты обработчики исключений должны быть способны быстро обрабатывать блокировки и обеспечивать, чтобы проблемные транзакции завершались чисто и без задержек.

Пора дальше

Далее мы рассмотрим транзакции с точки зрения разработчика клиентских приложений. Темы в этой главе являются нейтральными к включающим языкам. Тем не менее все современные средства разработки приложений и драйверы для Firebird используют один и тот же API в той или иной форме, что хорошо для одного, хорошо и для другого.

ГЛАВА 27. Программирование с транзакциями.

Транзакция является начальной точкой для всех взаимодействий клиентского приложения с сервером. В этой главе мы с точки зрения различных интерфейсов клиента рассмотрим запуск, управление и завершение транзакций.

Многие языки и средства разработки имеют интерфейс с Firebird. Подробное описание управления транзакциями Firebird в каждом из них находится за пределами данной книги.

Язык для транзакций

Важно обратиться к средствам реализации транзакций в Firebird. До сих пор некоторые связанные с транзакциями особенности вовсе не реализованы в динамическом SQL, а только через API. Среди небольшого количества связанных с транзакциями операторов SQL и доступных в подмножестве DSQL только COMMIT и ROLLBACK доступны в каждом интерфейсе. В книге осознанно выбран нейтральный подход к языкам средств разработки. Основной акцент делается на динамический SQL, используемый в большинстве существующих средств разработки клиентских приложений. В главе представлены некоторые проблемы, одинаково актуальные и для автора, и для читателя.

Хотя эта глава не описывает ESQL^[98] или API^[99], следующие разделы будут рассказывать о них в более или менее общем виде для получения некоторого понимания того, что передается через интерфейс, когда клиенты «беседуют» с серверами о транзакциях.

ESQL

Надмножество операторов SQL и подобных SQL операторов, используемых в прежние времена, даже до публикации API и подмножества DSQL, представляет синтаксис стандарта SET TRANSACTION для конфигурирования и старта транзакций. В некоторых формах он доступен в DSQL и может быть использован в утилите isql. Это удобное средство общей проверки того, как API передает эквивалентную информацию^[100].

API

API предоставляет гибкий интерфейс множества сложных функций программистам С и C++ для создания клиентских приложений с наиболее тонким уровнем связи и соединения. Группа функций API реализует эквивалентные операторы SQL, относящиеся к транзакциям, например isc_start_transaction() для оператора START TRANSACTION и isc_commit_transaction() для оператора COMMIT.

Заголовочный файл API, ibase.h, объявляет прототипы функций, определения типов для каждой структуры, определения параметров и макросы, которые используются в функциях. Он поставляется в каталоге Firebird /include.

Для некоторых объектно-ориентированных сред разработки, таких как Object Pascal, Borland C++ Builder, Java, PHP, Python и DBI::Perl классы и компоненты полностью инкапсулируют вызовы API Firebird, относящиеся к транзакциям. Пользовательские драйверы для интерфейсов соединения со стандартными базами данных SQL — в особенности ODBC, JDBC и .NET- похожим образом представляют API^[101].

Запуск транзакции

SQL

Оператор SQL для запуска транзакции имеет следующий синтаксис:

SET TRANSACTION [NAME <имя-транзакции>]

[READ WRITE | READ ONLY] /* режим доступа */

[WAIT | NO WAIT] /* режим разрешения блокировок */

[ISOLATION LEVEL] /* уровень изоляции */

{SNAPSHOT [TABLE STABILITY] | READ COMMITTED [[NO] RECORD VERSION]}

[RESERVING <предложение-резервирования>

| USING <дескриптор-базы-данных> [,дескриптор-базы-данных…]];

Финальное предложение RESERVING задает необязательное резервирование таблиц, обсуждавшееся в предыдущей главе. Его синтаксис представляется в виде:

<предложение-резервирования> : := <таблица> [, <та&лица> …] [FOR [SHARED | PROTECTED] {READ | WRITE}]

[, <предложение-резервирования> [, <предложение-резервирования> …]]

! ! !

ПРИМЕЧАНИЕ. Необязательное имя транзакции — объявляемое в приложении и указываемое в предложении SET TRANSACTION — недоступно нигде, кроме ESQL.

. ! .

Вы можете проверить этот оператор в isql. Откройте базу данных employee.fdb и запустите новую транзакцию следующим образом:

SQL> COMMIT;

SQL> SET TRANSACTION READ WRITE ISOLATION LEVEL SNAPSHOT TABLE STABILITY;

SQL> SELECT EMP_NO, FIRST_NAME, LAST_NAME

CON> FROM EMPLOYEE WHERE FIRST_NAME = ‘Robert’;

EMP NO FIRST NAME LAST NAME

==========================

2 Robert Nelson

SQL>

! ! !

СОВЕТ. Ключевые слова ISOLATION LEVEL являются необязательными, READ WRITE и WAIT являются значениями по умолчанию и могут быть опущены, если не требуются другие значения.

. ! .

Затем откройте другое окно командной строки и запустите isql или другой инструмент, который позволит вам конфигурировать тарнзакции, и запустите другую транзакцию чтения/записи для той же базы данных:

SQL> COMMIT;

SQL> SET TRANSACTION READ WRITE NOWAIT SNAPSHOT;

Теперь через тот же интерфейс попытайтесь изменить любую строку в базе данных tmployee.fdb:

SQL> UPDATE EMPLOYEE SET FIRST_NAME = ‘Dodger’

SQL> WHERE FIRST_NAME = ‘Roger’;

ISC ERROR CODE:335544345

lock coflict on no wait transaction (конфликт блокировки для транзакции, не являющейся ожидаемой)

Как и ожидалось, эта транзакция будет заблокирована для записи любой строки таблицы EMPLOYEE, потому что при выборе данных из той же таблицы первая транзакция запросила блокировку на уровень таблицы. Вторая тарнзакция имеет установку разрешения блокировки NOWAIT и немедленно выдает исключение, потому что не может выполнить изменение.

Транзакция по умолчанию

Следующий оператор также допустим:

SQL> COMMIT;

SQL> SET TRANSACTION;

Он запускает транзакцию, как и большинство операторов, с конфигурацией по умолчанию, что эквивалентно:

SQL> COMMIT;

SQL> SET TRANSACTION READ WRITE WAIT SNAPSHOT;

! ! !

ПРИМЕЧАНИЕ. Существует еще «транзакция по умолчанию», которая используется в клиентах ESQL для сконфигурированной единой транзакции, определенной на сервере и клиенте константой gds trans. Клиент ESQL стартует эту транзакцию автоматически, если он передает оператор запроса, а перед этим никакая транзакция явно не запускалась.

. ! .

API

Функция API, которая выполняет эквивалентную работу, называется isc_start_transaction()^[102]

Запуск каждой транзакции имеет три части:

1. Создание (при необходимости) и инициализация дескриптора транзакции.

2. Создание (при необходимости) и заполнение буфера параметров транзакции (Transaction Parameter Buffer, TPB) для хранения данных конфигурации. Это не обязательно.

3. вызов isc_start_transaction().

При отсутствии необязательного TPB клиент запускает транзакцию точно так же, как и транзакцию по умолчанию, которая стартует при выдаче оператора SET TRANSACTION.

Дескриптор транзакции

Каждый раз, когда вы собираетесь вызвать эту функцию, вы должны иметь переменную, длинный указатель — называемую дескриптором транзакции — уже объявленную в вашем приложении и инициализированную нулем^[103]. Приложение должно иметь один дескриптор транзакции для каждой конкурирующей транзакции, вы также можете повторно использовать дескрипторы, заново проинициализировав их.

Дескриптор транзакции должен быть установлен в ноль при его инициализации до запуска транзакции. Транзакция завершится с ошибкой, если ей будет передан ненулевой дескриптор.

Буфер параметров транзакции

TPB является байтовым массивом (или вектором) констант, каждая из которых представляет параметр транзакции и начинается с префикса isc_tpb_. Первым параметром всегда является константа isc_tpb_version3, которая определяет версию структуры TPB^[104]. Все последующие элементы массива являются константами, которые представляют эквивалентные SQL атрибуты транзакции.

В табл. 27.1 показаны параметры транзакции SQL и эквивалентные им константы TPB.

Типичное объявление TPB в языке С выглядит следующим образом:

static char isc_tpb[] =

{

isc_tpb_version3,

isc_tpb_write,

isc_tpb_wait,

isc_read_committed,

isc_tpb_no_rec_version

};

Этот TPB по своему действию идентичен следующему:

SET TRANSACTION READ WRITE WAIT READ COMMITTED NO RECORD_VERSION;

Вы можете использовать один TPB для всех транзакций, которым требуются одинаковые характеристики. Хорошим решением также является использование отдельного TPB для каждой транзакции. Классы транзакций обычно создают экземпляр TPB при необходимости, каждый экземпляр хранит установки интерфейса времени проектирования или времени выполнения в виде свойств, допускающих чтение и запись (или, иначе, элементы данных).

В большинстве случаев вы можете распознать константу TPB по имени свойства (табл. 27.1). В стандартных драйверах DBC имена классов и их элементов больше всего диктуются требованиями стандарта и описывают атрибуты с большим соответствием задаваемой функциональности.

Таблица 27.1. Атрибуты транзакции и эквивалентные константы TPB

Тип атрибута	Атрибут SQL	Константа TPB
Режим доступа	READ ONLY	isc_tpb_read
	READ WRITE	isc_tpb_write
Уровень изоляции	READ COMMITTED	isc_tpb_read committed
	SNAPSHOT	isc_tpb_concurrency
	SNAPSHOT TABLE STABILITY	isc_tpb_consistency
Режим разрешения блокировок	WAIT	isc_tpb_wait
	NO WAIT	isc_tpb_nowait
Версия записи	RECORD_VERSION	isc_rec version
	NO RECORD_VERSION	isc_no_rec_version
Резервирование таблиц	SHARED	isc_tpb_shared
	PROTECTED	isc_tpb_protected
	READ	isc_tpb_lock_read
	WRITE	isc_tpb_lock_write
Нет эквивалента SQL	Отключает протокол автоотмены	isc_tpb_no auto undo

Протокол автоотмены

По умолчанию сервер поддерживает в памяти протокол внутренних точек сохранения (internal savepoint log) для добавляемых и изменяемых строк. При нормальном течении процесса записи протокола удаляются при каждом подтверждении или откате транзакции. Однако при некоторых условиях система отказывается от протокола и напрямую обращается к глобальному образу состояния транзакции (TSB). Такой переход обычно происходит, когда отменится очень большое количество добавлений или транзакция, использующая множество пользовательских точек сохранения (см. разд. «Вложенные транзакции»), исчерпает возможности этого протокола.

Приложение может отключить использование в транзакции этого протокола автоотмены, передав константу isc_tpb_no_auto_undo в TPB.

Доступ к идентификатору транзакции

Начиная с Firebird 1.5 идентификатор (TID) текущей транзакции (который получается из хранимых данных состояния транзакции) доступен в виде контекстной переменной. Он доступен в DSQL, isql, триггерах и хранимых процедурах. Это переменная CURRENT_TRANSACTION.

Например, для получения идентификатора в запросе вы можете выполнить следующее:

SELECT CURRENT_TRANSACTION AS TRAN_ID FROM RDВ$DATABASE;

Для сохранения его в таблице нужно выполнить:

INSERT INTO TASK_LOG (USER_NAME, TRAN_ID, START_TIMESTAMP)

VALUES (CURRENT_USER, CURRENT_TRANSACTION, CURRENT_TIMESTAMP) ;

! ! !

ВНИМАНИЕ! Идентификаторы транзакции не являются достаточно стабильными, чтобы их использовать в качестве ключей. Серия номеров для идентификаторов транзакций будет устанавливаться в 1 каждый раз при восстановлении базы данных.

. ! .

Firebird 1.0.x не предоставляет механизма отслеживания транзакций.

Использование TID в приложениях

Идентификатор транзакции на сервере не является тем же самым, что и дескриптор транзакции, который клиент Firebird получает в свое приложение. Довольно обоснованным является ассоциирование идентификатора транзакции с дескриптором транзакции при условии, что вы помните о необходимости изменить отношение между идентификатором и дескриптором транзакции при новой инициализации дескриптора. Каждое использование дескриптора в вашем приложении должно быть атомарным.

Идентификатор транзакции может быть полезным при отслеживании приложений и пользователей, ответственных за долгие транзакции в системе, ухудшающие ее производительность. Служебная программа циклического отслеживания может записывать на сервер время старта и завершения транзакций (подтверждение или отмена). В частности, отсутствие времени завершения будет полезным для отыскания пользователей, привычно использующих кнопку «восстановить» для завершения задач, или приложений, в которых регулярно происходит отказ при подтверждении работы.

Процесс выполнения транзакции

К настоящему моменту у вас уже должно быть чувство уверенности по поводу вида операций многопользовательской системы, как серии атомарных задач, изолированных в транзакциях. Задачи будут выполнены, когда клиенты запускают транзакции и когда клиенты их завершают. Помимо конфигурирования транзакции для задания задаче условий доступа, изоляции и способа разрешения блокировок, клиент имеет другие возможности для взаимодействия с транзакцией в процессе ее выполнения. На рис. 27.1 показаны подобные точки этого взаимодействия. В остальных разделах настоящей главы более подробно рассматриваются техника и реализация таких задач.

Вложенные транзакции

В Firebird транзакции всегда запускаются и завершаются клиентом. Некоторые другие СУБД могут запускать и подтверждать транзакции из хранимых процедур, потому что для управления транзакциями они используют двухфазную блокировку транзакций. Вместо этого Firebird предоставляет другие механизмы, которые могут оперировать с потоком работы в транзакции без нарушения атомарности. Два из этих механизмов, блоки обработчика исключений и выполняемые строки, ограничены по использованию только в модулях PSQL и обсуждаются в части VII. Другим механизмом, недоступным в PSQL, являются пользовательские точки сохранения.

Рис. 27.1. Взаимодействие приложения и транзакции

! ! !

ПРИМЕЧАНИЕ. Выполняемые строки и пользовательские точки сохранения являются новыми возможностями, добавленными в язык в Firebird 1.5.

. ! .

Пользовательские точки сохранения

Операторы пользовательских точек сохранения (user savepoints), также называемые вложенными транзакциями, позволяют вам «упаковать» группы операций внутри транзакции и отмечать их, если пересылка в базу данных была успешной. Если позже в последовательности задач появится исключение, транзакция может выполнить откат к последней точке сохранения. Операции, отправленные в базу между этой точкой сохранения и возникшим исключением, будут отменены, а приложение может выполнить корректировку, подтверждение, полный откат, продолжить работу — в зависимости от того, что требуется сделать.

Создание пользовательских точек сохранения

Пользовательские точки сохранения являются операцией клиентской стороны, доступной только в операторах DSQL.

Оператором создания пользовательской точки сохранения является:

SAVEPOINT <идентификатор>;

Идентификатор может быть любым правильным идентификатором SQL Firebird (максимум 31 алфавитно-цифровой символ ASCII, уникальный в транзакции). Вы можете заново использовать тот же идентификатор в той же транзакции, он перекроет существующую точку сохранения, связанную с этим именем.

Возврат на точку сохранения

Возврат (или откат, rollback) на точку сохранения начинается с отмены всей работы, выполненной и отправленной в базу данных после создания этой точки сохранения. Указанная точка сохранения и все предшествующие ей сохраняются. Любые точки сохранения, которые были созданы после указанной точки сохранения, пропадают.

Любые блокировки (явные и неявные), которые были установлены с момента создания указанной точки сохранения, будут сняты. При этом транзакции, которые были заблокированы при ожидании доступа к освобожденным строкам, все еще не получат к ним доступ, пока не завершится текущая транзакция. Это гарантирует, что ожидающие в настоящий момент конкуренты не повлияют на поток работы, когда он будет возобновлен. Все это не повлияет на транзакции, которые не находились в состоянии ожидания в момент вложенного отката.

Вот шаблон синтаксиса для отката на точку сохранения:

ROLLBACK [WORK] ТО [SAVEPOINT] <идентификатор>;

Если транзакция позволяет продолжить работу после отката на точку сохранения, то в дальнейшем работа может осуществлять откат на эту точку сохранения столько раз, сколько потребуется. Версии записей, которые были отменены откатом, не будут доступны для сборщика мусора, потому что транзакция все еще является активной.

Освобождение точек сохранения

Механизм реализации точек сохранения на сервере — протокол в памяти — может требовать значительного количества ресурсов, особенно если одни и те же строки изменяются многократно в процессе выполнения задачи. Ресурсы уже ненужных точек сохранения могут быть освобождены при использовании оператора RELEASE

SAVEPOINT:

RELEASE SAVEPOINT <идентификатор> [ONLY];

Без ключевого слова ONLY указанная точка сохранения и все точки сохранения, которые были созданы после нее, будут освобождены и потеряны. Используйте ONLY для освобождения только указанной точки сохранения.

Следующий пример иллюстрирует работу точек сохранения:

CREATE TABLE SAVEPOINT_TEST (ID INTEGER);

COMMIT;

INSERT INTO SAVEPOINT_TEST

VALUES(99);

COMMIT;

INSERT INTO SAVEPOINT_TEST

VALUES(100) ;

/**/

SAVEPOINT SP1;

/**/

DELETE FROM SAVEPOINT_TEST;

SELECT * FROM SAVEPOINT_TEST; /* не вернет ничего */

/**/

ROLLBACK TO SP1;

/**/

SELECT * FROM SAVEPOINT_TEST; /* вернет 2 строки */

ROLLBACK;

/**/

SELECT * FROM SAVEPOINT_TEST;

/* вернет одну подтвержденную строку */

Внутренние точки сохранения

Когда ядро сервера выполняет откат, его контрольная точка по умолчанию для отменяемой транзакции ссылается на внутреннюю точку сохранения, находящуюся в протоколе автоотмены в оперативной памяти. При завершении отката он подтверждает транзакцию. Целью этой стратегии является сокращение количества мусора, порождаемого откатами.

Когда объем изменений, выполненных перед точкой сохранения на уровне транзакции, становится большим — в пределах от 10 000 до 1 миллиона строк — ядро сервера прекращает использовать протокол автоотмены и получает ссылки напрямую из глобального образа состояния транзакции (TSB). Если у вас есть транзакция, в которой цы предполагаете выполнение операции с большим количеством изменений, отключение ведения протокола автоотмены предотвратит утечку потребляемых ресурсов, которая появится, если ваш сервер решит отменить ведение протокола. Подробности см. в разд. «Протокол автоотмены» ранее в этой главе.

PSQL

Расширения для обработки исключений

Эквивалентом точек сохранения в модулях PSQL является обработка исключений. Каждый блок PSQL для обработки исключений также ограничен автоматической системой точек сохранения. Расширения PSQL предоставляют языковую оболочку для реализации того же типа вложенности транзакций, что и пользовательские точки сохранения в DSQL. Подробности см. в главе 32.

Логический контекст

Простой способ рассматривать транзакцию между START TRANSACTION и COMMIT или ROLLBACK — это смотреть на нее как на серию клиентских операций и взаимодействий клиента и сервера, которые точно отображают задачу. Это очень полезная модель для понимания того, как транзакция создает обертку для единицы работы. Эта модель не обязательно точно отражает то, как именно пользователи выполняют конкретные задачи.

С пользовательской точки зрения «задача» не ограничена операторами START TRANSACTION и COMMIT. Его задача имеет начало, середину и окончание, что может включать множество транзакций. Например, ошибки при пересылке или подтверждении оператора повлекут за собой откат для завершения физической транзакции. Некоторые виды вмешательств могут привести к завершению логической задачи или в нормальном случае потребуют другой физической транзакции для завершения логической задачи.

Одна физическая транзакция может включать множество дискретных пользовательских задач, формирующих логическое «целое», что требует атомарности единой физической транзакции. Другой вариант- типичная задача «пакетного ввода данных» — выполняет многократные повторения похожей задачи, помещенные внутрь одной физической транзакции для сокращения количества нажатий клавиш клавиатуры и соответствия пользовательским требованиям выполнения работы.

Подводя итог, логическая задача — это то, что мы как разработчики должны проектировать и к чему обращаться — почти всегда выходит за пределы границ START TRANSACTION и COMMIT. Физическая транзакция при этом является частью логического контекста.

Двумя ключевыми факторами в отношении логического контекста транзакции являются:

* как сохранять физический контекст начальной транзакции после ROLLBACK, чтобы работа пользователя не пропала, когда сервер отменит доступ;

* что делать, если поток работы будет прерван исключением — как диагностировать исключение и как его скорректировать.

Для решения этих задач мы рассмотрим операции COMMIT и ROLLBACK, а также все за и против использования доступных режимов для сохранения логического контекста транзакций. После этого мы рассмотрим вопросы диагностирования исключений, которые могут потребовать повторного запуска транзакций.

Завершение транзакций

Транзакция завершается, когда клиентское приложение подтверждает ее или отменяет. Если оператор COMMIT или вызов эквивалентной функции API isc_commit_ transaction не будут успешными, то транзакция не будет подтверждена. Если транзакция, которая не может быть подтверждена, не будет отменена явным вызовом клиентом ROLLBACK (ИЛИ функцией API isc_roiiback_transaction), транзакция не будет отменена. Эти операторы не являются силлогизмом. Ошибки при завершении транзакций являются весьма общей проблемой, часто обсуждаемой в публичных конференциях!

Оператор COMMIT

Синтаксис оператора COMMIT:

COMMIT [WORK] [RETAIN [SNAPSHOT]];

Простой COMMIT — иногда называемый жестким подтверждением по причинам, которые станут понятными, — делает изменения, отправленные в базы данных, постоянными и освобождает все физические ресурсы, связанные с транзакцией. Если по различным причинам COMMIT завершается с ошибкой и возвращает клиенту исключение, транзакция остается в неподтвержденном состоянии. Клиентское приложение должно обработать ошибку подтверждения транзакции, выполнив ее явный откат или, если это возможно, исправив ошибку и заново выполнив оператор.

COMMIT с режимом RETAIN

Необязательное расширение RETAIN [SNAPSHOT] оператора COMMIT приводит к тому, что сервер сохраняет «образ» контекста физической транзакции и производит запуск новой транзакции как клона подтвержденной транзакции. Если это так называемое мягкое подтверждение используется в транзакциях SNAPSHOT или SNAPSHOT TABLE STABILITY, клонируемая транзакция при своем запуске сохраняет тот же образ данных, что и исходная транзакция.

Хотя это приводит к постоянному подтверждению работы и, следовательно, изменяет состояние базы данных, COMMIT RETAIN (CommitRetaining) не освобождает ресурсы. На отрезке жизни логической задачи, которая включает в себя множество повторений похожих операций, клонирование контекста уменьшает некоторые накладные расходы, которые могли бы возникнуть при освобождении ресурсов каждый раз при COMMIT; при этом сначала лишь выделяются идентичные ресурсы при старте новой транзакции. В частности, это сохраняет «открытые» в настоящий момент курсоры для выбранных наборов.

Тот же самый идентификатор транзакции остается активным в TSB и никогда не становится «подтвержденным». По этой причине такое действие часто называется мягким подтверждением (soft commit) по сравнению с «жестким» подтверждением, выполняемым немодифицированным оператором COMMIT.

Каждое мягкое подтверждение похоже на точку сохранения без возможности возврата к ней. Все последующие операторы ROLLBACK отменяют только те изменения, которые были отправлены на сервер после последнего мягкого подтверждения.

Преимущество мягкого подтверждения в том, что оно облегчает жизнь программиста, особенно тех, кто использует компоненты, которые реализуют поведение «прокручиваемой базы данных». Это было сделано для поддержки сетки данных (grid) в пользовательском интерфейсе, используемой многими пользователями среды разработки Borland Delphi (и C++ Builder). Сохраняя контекст транзакции, приложение может отображать плавный переход состояния до-и-после, что сокращает работу программиста, которому иначе пришлось бы стартовать новые транзакции, открывать новые курсоры и заново синхронизировать их с наборами строк, хранящимися на клиенте.

Различные реализации доступа к данным часто объединяют пересылку на сервер единичного изменения, добавления или удаления с немедленным COMMIT RETAIN В механизм, дублирующий «автоподтверждение». Общим для уровней интерфейса является реализация возможности автоподтверждения для «молчаливого» управления транзакцией, запуская транзакцию невидимо для программиста в ситуациях, когда написанный программистом код пытается передавать оператор без предварительного старта транзакции.

Явное управление транзакциями стоит дополнительных усилий, особенно если вы применяете продукт, использующий такие гибкие средства, которые предоставляет Firebird. В загруженном работой окружении вариант COMMIT RETAIN может сократить время выполнения и ресурсы, однако он имеет некоторые серьезные недостатки.

* Транзакция SNAPSHOT продолжает хранить первоначальный образ базы данных, что означает, что пользователь не видит подтвержденных результатов других транзакций, которые ожидали подтверждения при старте текущей транзакции.

* Пока та же транзакция продолжает выполнять подтверждение в варианте RETAIN, ресурсы, используемые на сервере, не освобождаются, что приводит к чрезмерному росту ресурсов памяти, потребляемых TSB. Этот рост сильно ухудшает производительность, в конечном счете «замораживая» сервер, и при неблагоприятных условиях операционной системы даже может привести к краху системы.

* Никакие старые версии записей, ставшие устаревшими в результате операций, подтвержденных в транзакциях COMMIT RETAIN, не могут быть включены в сборку мусора, т. к. исходная транзакция никогда не выполняет «жесткого подтверждения».

Оператор ROLLBACK

Как и COMMIT, оператор ROLLBACK освобождает ресурсы на сервере и завершает физический контекст транзакции. При этом вид состояния базы данных в приложении возвращается к тому виду, как если бы эта транзакция никогда не стартовала. В отличие от COMMIT данный оператор никогда не завершается с ошибкой.

В логическом контексте «задачи» клиента после отката транзакции ваше приложение должно предоставить пользователю средства для разрешения проблем, которые вызвали исключение, и для повторного запуска новой транзакции.

RollbackRetaining

SQL в Firebird не реализует синтаксис RETAIN В ROLLBACK так же, как это делается в COMMIT. При этом похожий механизм клонирования реализован в функции API isc_roiiback_retaining(). Она восстанавливает для приложения вид базы данных в то состояние, которое было, когда транзакция получила дескриптор или, в случае транзакции READ COMMITTED, в то состояние, которое было при последнем вызове

isc_roiiback_retaining(). Выделенные для транзакции системные ресурсы не освобождаются, курсоры сохраняются.

ROLLBACK RETAIN имеет те же самые ловушки, что и COMMIT RETAIN — и даже больше. Поскольку отдельные вызовы откатов производятся в ответ на исключение некоторого вида, сохранение контекста транзакции также сохранит и причины исключения. ROLLBACK RETAIN не должен использоваться в тех

случаях, если существует шанс, что ваш последующий код обработки исключения не найдет и не исправит наследуемое исключение. Любые последующие ошибки ROLLBACK RETAIN должны обрабатываться с полным откатом транзакции для освобождения ресурсов и устранения проблемы.

Диагностирование исключений

Основные причины возникновения ошибок при пересылке данных или подтверждении работы включают:

* конфликты блокировок;

* «плохие данные», полученные от интерфейса пользователя: арифметическое переполнение, деление на ноль в выражениях, пустые значения в полях, не допускающих пустых значений, несоответствие набора символов и т.д.;

* «хорошие данные», которые нарушают ограничение CHECK или другие проверки;

* нарушения первичного или внешнего ключей;

* и другие!

Firebird распознает большое количество различных (более того, поразительных!) исключений и возвращает код ошибки для их идентификации на двух уровнях:

* на высоком уровне существует переменная SQLCODE, определенная (более или менее, с ударением на «менее») в стандарте SQL;

* на более детальном уровне присутствует GDSCODE — индикатор большего размера, более точно определяющий тип исключений, которые сгруппированы на предыдущем уровне в типе SQLCODE.

SQLCODE

В табл. 27.2 представлены значения стандартов SQL-89 и SQL-92, определенные для SQLCODE.

Таблица 27.2. Значения SQLCODE

SQLCODE	Сообщение	Интерпретация
0	SUCCESS	Операция завершилась успешно
1-99	SQLWARNING	Предупреждающее или информационное сообщение сервера
100	NOT FOUND	Была запрошена операция, для которой не было найдено строк. Это не ошибка — код часто просто сообщает о том, что определено условие «конец файла» или «конец курсора» или что не найдено соответствующих значений
<0	SQLERROR	Указывает, что оператор SQL не был завершен. Числа находятся в диапазоне от -1 до -999

Описание отрицательных значений SQLCODE для конкретных ошибок не содержится в стандартах. Отрицательные значения SQLCODE в Firebird являются довольно обобщенными, они представлены группами, которые в значительной степени получены случайно и очень часто своим составом изумляют. Например, можно установить, что значение SQLCODE -204 означает «нечто неизвестное», однако сам код ничего не говорит, что именно неизвестно.

GDSCODE

Второй уровень, GDSCODE, предоставляет гораздо больше возможностей определения исключений. Каждый код GDSCODE является знаковым целым, константы которого представлены в iberror.h (или в interbase.msg, если вы используете версию 1.0.x)^[105]. Как правило, сообщение GDSCODE достаточно точно указывает, что произошло^[106]. В Firebird 1.5 значительно улучшена информация, передаваемая в сообщениях. Тем не менее GDSCODE предоставляет для приложений наиболее полезный механизм диагностики; вы можете преобразовать константы в пользовательские сообщения в вашем модуле на включающем языке для использования в обработчиках исключений.

Получение исключений

В следующем примере приложение делает попытку добавить данные в таблицу, которая не существует:

INSERT INTO NON_EXISTENT (TEST)

VALUES (‘ABCDEF’);

Следующая информация об ошибке возвращается приложению (утилита администратора IB SQL в этом случае):

ISC ERROR CODE:335544569 <- GDSCODE

Dynamic SQL Error <- corresponding text from firebird.msg

SQL error code = -204 <- SQLCODE

Table unknown <- corresponding text from firebird,msg

NON_EXI STENT

Откуда приложение получает коды ошибок и сообщения? Ответ можно найти в векторе состояния ошибки (error status vector), в массиве, который передается в качестве параметра в большинство функций API. Эти функции возвращают состояние и коды ошибок клиенту вместе с соответствующими строками из файла сообщений Firebird^[107]. API также предоставляет клиентским приложениям служебные функции для чтения содержимого векторов состояния ошибок в локальных буферах. Обработчики ошибок могут затем анализировать содержимое этих буферов и использовать полученную информацию для принятия решения, как поступить с исключением, а также выдать пользователю дружественное сообщение.

iberror.h

Заголовочный файл iberror.h в вашем каталоге /include содержит объявления, каждое из которых связано с SQLCODE и GDSCODE через символическую константу. Например, вот объявления констант для двух кодов ошибок из предыдущего примера:

. . .

#define isc_dsql_error 335544569L

. . .

#define isc_dsql_relation_err 335544580L <- an SQLCODE -204 error

Большинство из существующих языков высокого уровня и интерфейсов сценариев уже имеют транслированные объявления констант. Если вам нужна трансляция, рекомендуется обратиться к спискам поддержки. Полный список кодов SQLCODE, GDSCODE и стандартных сообщений на английском языке находится в приложении 10. Использование этих кодов ошибок и расширений языка в PSQL является темой главы 32.

Транзакции для нескольких баз данных

Firebird поддерживает операции над несколькими базами данных под управлением одной транзакции. Он автоматически реализует двухфазное подтверждение (Two- Phase Commit, 2РС), чтобы гарантировать, что транзакция не подтвердит работу в одной базе данных, пока не будет возможности подтвердить работу в других базах данных. Данные никогда не будут частично подтвержденными.

На первой фазе двухфазного подтверждения или отката Firebird подготавливает к подтверждению (или откату) работу в каждой базе данных, разделяя транзакцию на

подтранзакции, по одной для каждой базы данных, и посылает (post) изменения в каждую базу данных. В этот момент все подтранзакции имеют «переходное» состояние. Если первая фаза завершается, то на второй фазе каждая подтранзакция отмечается для подтверждения или отката в том же порядке, в котором каждые части были подготовлены.

* Если это операция подтверждения и какая-нибудь подтранзакция не может быть подтверждена, возникает исключение. Все подтранзакции, отмеченные для подтверждения, переводятся в «переходное» состояние, а состояние базы данных не изменяется ни при каких условиях.

* Если подтверждение везде выполнилось успешно, то все подтранзакции переводятся в состояние «подтвержденные», а изменения базы данных становятся постоянными.

* Если это операция отката, то подтранзакции переводятся в состояние отмены.

Зависшие транзакции

Если нарушения в сети или ошибки диска делают одну или более баз данных недоступными, то двухфазное подтверждение завершается с ошибкой на второй фазе, подтранзакции остаются в их переходном состоянии, будучи отмеченными ни как подтвержденные, ни как отмененные. В каждой из этих баз данных такие подтранзакции никогда не будут завершены на второй фазе (не станут подтвержденными или отмененными). Такие транзакции называются зависшими (limbo).

Поскольку строки в базе данных иногда становятся недоступными по причине их связи с зависшими транзакциями, становится важным разрешать такие транзакции.

Восстановление

Пока зависшая транзакция не будет завершена (подтверждена или отменена), она остается «заинтересованной» в Firebird, который сохраняет статистику по незавершенным транзакциям. Восстановление зависшей транзакции означает ее подтверждение или отмену. Утилита gfix может восстановить зависшие транзакции и позволяет вам взаимодействовать с ними интерактивно. Более подробную информацию см. в главе 39.

! ! !

Примечание. В базах данных, с которыми работают с помощью драйверов, не использующих двухвфазное подтверждение, таких как Borland Database Engine (BDE), никогда не возникает зависших транзакций.

. ! .

Ограниченные базы данных

Транзакции над несколькими базами данных могут использовать много ресурсов сервера. В ESQL Firebird предоставляет языковую поддержку в форме предложения USING для ограничения баз данных, к которым транзакциям разрешен доступ. DSQL не предоставляет языковую поддержку. Интерфейсы DSQL могут использовать структуры API в блоке параметров транзакции для ограничения транзакций с множеством баз данных различными способами. Некоторые классы компонентов доступа к данным предоставляют доступ к этим режимам через свойства.

Пессимистическая блокировка

В пессимистической блокировке СУБД строки, запрошенные одним пользователем или транзакцией для операции, которая может изменить состояние данных, немедленно становятся недоступными для чтения или записи другим пользователям или транзакциям. В некоторых системах недоступной становится целая таблица. Многие разработчики, переносящие базы данных и приложения в Firebird из подобных систем, приходят в замешательство из-за оптимистической блокировки и безнадежно отыскивают способы подражать старому.

В Firebird все изменения выполняются на уровне строки — не существует механизма блокировки отдельного столбца. Почти на всех уровнях изоляции транзакции ядро сервера осуществляет принцип оптимистической блокировки: все транзакции, не ограниченные какой-либо формой пессимистической блокировки, начинаются с просмотра текущего подтвержденного состояния всех строк во всех таблицах- конечно, при соответствующих привилегиях. Когда транзакция передает запрос на изменение строки, старая версия этой строки остается видимой всем транзакциям. Писатели не блокируют читателей.

При успешном выполнении изменения сервер внутренне создает новую версию строки, которая неявно блокирует исходную версию. В зависимости от установок этой пользовательской транзакции и других транзакций появится конфликт блокировки некоторого уровня, если другая транзакция попытается изменить или удалить заблокированную строку. Подробности об условиях блокировки Firebird см. в главе 26.

Firebird разработан для интерактивного использования многими конкурирующими пользователями; редко можно найти подлинные причины для использования пессимистической блокировки. Это не «магическая пуля», с помощью которой нужно эмулировать поведение настольных СУБД. Пессимистические блокировки одной транзакции приведут к конфликтам в других транзакциях. Нет возможности уйти от ответственности при работе с многопользовательской моделью транзакций и написании обработчиков предполагаемых конфликтов блокировки.

Блокировка на уровне таблицы

Уровень изоляции транзакции TABLE STABILITY (или согласованная изоляция) предоставляет полную блокировку таблицы по записи, включая зависимые таблицы. Этот уровень слишком агрессивен для интерактивных приложений.

Более предпочтительным является использование предложения RESERVING с уровнями изоляции READ COMMITTED и SNAPSHOT, потому что оно предоставляет больше гибкости и управляемости для таблиц, которые вы хотите заблокировать в процессе выполнения транзакции. Предложение содержит параметры, которые определяют требуемый объем защиты для каждой таблицы:

RESERVING <предложение -резервирования>;

<предложение-резервирования> = table [, table …]

[FOR [SHARED f PROTECTED] {READ | WRITE}]

[, <предложение-резервирования>]

<предложение-резервирования> может включать в себя множество спецификаций резервирования наборов, предоставляя возможность резервировать различные таблицы или группы таблиц с различными правами. Конкретная таблица должна появляться только один раз в предложении резервирования. Обратитесь к предыдущей главе для получения информации о резервировании таблиц.

Блокировка на уровне оператора

Пессимистическая блокировка на уровне оператора — влияющая на индивидуальные строки или наборы — не является прямым вопросом конфигурации транзакции. При этом воздействие этих типов блокировок напрямую управляется установками транзакций в транзакции, в которой определена блокировка, и в других транзакциях, которые пытаются получить доступ к блокированной строке или набору. Это является основным решением в рамках таких техник в терминах установок транзакции.

Пессимистическая блокировка строки или набора является противоположностью того способа работы, для которого был спроектирован Firebird. Короче говоря, если вы жили с пессимистической блокировкой и зависели от нее до знакомства с Firebird, то пришло время получить удовольствие от многоверсионной архитектуры и преимуществ оптимистической блокировки строки.

При этом нельзя отрицать, что иногда требования разработки вызывают необходимость пессимистической блокировки, хотя такая потребность бывает гораздо реже, чем в случае работы с другими СУБД. Тем не менее лучшим сценарием, включающим абсолютное требование исключительного доступа к строкам, не является блокировкой на уровне таблицы. Обычно прочитанная строка должна быть защищена от изменения или удаления. Такое требование иногда называется строгой сериализацией задач.

Для случаев, когда необходима пессимистическая блокировка на уровне строки, механизм пессимистической блокировки и поддерживаемый синтаксис SQL реализованы в версии 1.5. До этого сервер Firebird по существу этого не поддерживал. В данном разделе мы сначала посмотрим на стандартный «трюк», который выполняют клиентские приложения- когда для этого отсутствует языковая поддержка для получения пессимистической блокировки. Затем мы рассмотрим синтаксис и условия явного SELECT … WITH LOCK, который осуществляет поддержку пессимистической блокировки для SQL в Firebird 1.5.

Трюк «фиктивное изменение»

«Редактирование» не является деятельностью на стороне сервера, следовательно, когда пользователь щелкает по кнопке Редактировать (или использует любой другой интерфейс для редактирования данных), это ничего не изменяет на сервере. Пока сервер не озабочен изменениями, транзакция просто читает. Никаких новых версий записей не создается. Не существует блокировок. Ничто не изменяется, пока пользователь не завершит редактирование строки, и приложение фактически не отправит на сервер работу пользователя.

Разработчики, которые рассматривают такое поведение как сложную проблему, обманывают ситуацию, пересылая в своих приложениях «фиктивное изменение» строки, когда пользователь запрашивает ее редактирование. «Трюк» заключается в том, что оператор изменения устанавливает значение столбца в его текущее значение. Обычно используется столбец первичного ключа, например:

UPDATE ATABLE

SET PKEY = PKEY

WHERE PKEY = PKEY;

Следовательно, сервер создает новую версию записи, в которой нет никаких отличий от последней подтвержденной версии, и задает блокировку этой строки. Когда пользователь сообщает, что он завершил редактирование строки, приложение посылает на сервер реальное изменение, например:

UPDATE ATABLE

SET COLUMN2 = ‘Некоторое новое значение’,

C0LUMN3 = 99,

. . .

WHERE PKEY = <значение первичного ключа>;

На сервер пересылается еще одна новая версия записи, перекрывая первую.

Если вам действительно нужна пессимистическая блокировка и не существует комбинации атрибутов транзакции, которые подошли бы вашим специфическим потребностям, такая техника будет эффективной. Это работает только для одной строки и продолжается, пока транзакция не будет подтверждена, даже если пользователь решит не выполнять никаких изменений строки.

! ! !

ВНИМАНИЕ! Если вы используете эту технику, убедитесь, что триггеры условий BEFORE UPDATE и BEFORE DELETE, относящиеся к тем таблицам, которые используются в фиктивных изменениях, не помешают выполнению необходимых действий.

. ! .

! ! !

СОВЕТ. Может оказаться необходимым создание в вашей таблице специального скрытого столбца FLAG для специфического использования в качестве флага фиктивных изменений. Например, скрытый столбец типа данных INTEGER может увеличиваться на единицу вашим оператором, выполняющим фиктивное изменение. Тогда в триггерах можно задать выполнение «реальных» изменений только в случае IF (NEW.FLAG <> OLD.FLAG).

. ! .

О «дважды выполненных» изменениях

Не рекомендуется изменять одну и ту же строку более одного раза в одной транзакции, потому что это будет пересекаться как с автоматической целостностью данных (ссылочная целостность), так и с пользовательскими триггерами. Когда используются точки сохранения (savepoint), это приводит к сильному росту количества версий записей. Такое дублирование обычно является следствием небрежного проектирования логики приложения. При этом «дважды измененное изменение» является точной целью техники «фиктивных изменений». Если в этих транзакциях не используются точки сохранения, а в триггерах производится проверка на реальные изменения, все будет в безопасном состоянии.

Явная блокировка в версии 1.5 и более поздних

Синтаксис явной блокировки:

SELECT спецификация-выхода FROM имя-таблицы

[WHERE условие-поиска]

[FOR UPDATE [OF столбец1 [, столбец2 [, …]]]]

WITH LOCK;

Как это работает

Для каждой записи, попадающей под действие оператора с явной блокировкой, сервер возвращает либо самую последнюю подтвержденную версию записи, независимо от того состояния, которое имела база данных при передаче на сервер этого оператора, либо исключение.

Поведение ожидания и сообщение о конфликте зависят от параметров транзакции, заданных в буфере параметров транзакции (TPB).

Сервер гарантирует, что все записи, возвращенные оператором с явной блокировкой, являются заблокированными и соответствуют условиям поиска, заданным в предложении WHERE, если условия поиска не зависят от любых других таблиц, указанных, например, в соединении или подзапросе. Он также гарантирует блокировку только тех строк, которые соответствуют условиям поиска.

При этом потенциальный выходной набор зависит от установок транзакции: уровня изоляции, разрешения блокировок и версии записи. Строка не получит блокировку, пока она не будет отправлена в буфер строк на сервере. Не существует никаких гарантий, будет или не будет потенциальный набор воздействовать на параллельные транзакции, которые выполняют подтверждения в процессе выполнения оператора с блокировкой, делая другие строки подходящими для выборки в вашей транзакции.

В табл. 27.3 содержатся итоговые сведения о взаимодействиях между установками транзакции и явными блокировками. «Наша транзакция»- это транзакция, которая имеет или пытается получить явную блокировку строки или набора.

Если указано SELECT … WITH LOCK и необязательное предложение FOR UPDATE опущено, то все строки в наборе будут предварительно заблокированы, неважно, изменяете вы их фактически или нет. При аккуратном конфигурировании транзакции и управлении буферизацией со стороны клиента блокировка будет предотвращать доступ по записи к любой из этих строк или к зависимым от них строкам другим транзакциям, пока не завершится ваша транзакция. Предварительная блокировка набора, содержащего много строк, приведет к росту конфликтов блокировок, и ваш код приложения должен быть готовым к их обработке.

Таблица 27.3. Взаимодействие установок транзакции и явных блокировок

Изоляция	Разрешение блокировок	Поведение
isc_tpb_consistency (SNAPSHOT TABLE STABILITY)	— — —	Игнорируется. Блокировки на уровне таблицы перекрывают явные блокировки
isc_tpb_concurency (SNAPSHOT)	isc_tpb_nowait (NO WAIT)	Если строка была изменена любой транзакцией и подтверждена после старта нашей транзакции, или уже активная транзакция изменила строку до того, как она была помещена в кэш строк, то немедленно возникает исключение по конфликту изменения
isc_tpb_concurency (SNAPSHOT)	isc_tpb_wait (WAIT)	Если строка была изменена любой транзакцией и подтверждена после старта нашей транзакции, или уже активная транзакция изменила строку до того, как она была помещена в кэш строк, то немедленно возникает исключение по конфликту изменения. Если активная транзакция использует строку с явной блокировкой или с обычной блокировкой по записи, то наша транзакция ждет результатов блокирующей транзакции. Если блокирующая транзакция подтверждает затем измененную версию этой записи, то возникает исключение по конфликту изменения
isc_tpb_read committed (READ COMMITTED)	isc_tpb_nowait (NO WAIT)	Если активная транзакция использует строку с явной блокировкой или с обычной блокировкой по записи, то наша транзакция немедленно получает исключение по конфликту изменения
isc_tpb_read committed (READ COMMITTED)	isc_tpb_wait (WAIT)	Если активная транзакция использует строку с явной блокировкой или с обычной блокировкой по записи, то наша транзакция ждет результатов блокирующей транзакции. Когда блокирующая транзакция завершается, наша транзакция снова пытается установить блокировку на эту строку. Исключения по конфликту изменения никогда не возникнут для оператора с явной блокировкой с такой конфигурацией

Количество строк в указанном выходном наборе имеет важные последствия, если вы используете метод доступа, который запрашивает «наборы данных» или «наборы записей» в пакетах из нескольких сотен строк за один раз («буферизованная загрузка»), и буферизируете их на клиенте- обычно для реализации интерфейса прокручивания. Если блокировка не срабатывает в процессе получения отдельной строки и вызывает исключение, то ни одна из строк, находящихся в состоянии ожидания в буфере на сервере, не будет отправлена, а те, которые уже были переданы на клиентский буфер, станут ошибочными. Ваше приложение должно будет выполнить откат транзакции.

При таком стиле доступа важно обеспечить в ваших приложениях способ обработки исключений по мере их появления. Используйте сильно ограничивающее предложение WHERE для уменьшения диапазона блокировок до одной или очень небольшого количества строк и исключите ошибки в частично загруженных наборах. Если ваш интерфейс доступа к данным такое поддерживает, то сделайте в вашем компоненте доступа к данным буфер для загрузки только одной строки, например:

SELECT * FROM DOCUMENT

WHERE ID = ? WITH LOCK /* ID — первичный ключ */

Необязательное предложение FOR UPDATE предоставляет способ для определения набора из множества строк, загрузки и обработки строк за один раз.

Предложение FOR UPDATE

Если присутствует предложение FOR UPDATE, буферизованная загрузка будет отключена, а блокировка будет применяться к каждой строке, одна за другой в том порядке, в котором они загружаются из кэша с серверной стороны. Если именованный курсор^[108] управляет позицией обновления, это предложение может включать необязательное выражение ON <список-столбцов> для направления изменений указанным столбцам курсора.

Поскольку к транзакции применяются обычные правила изоляции, то существует возможность для блокировки, которая была доступна в момент старта запроса, впоследствии получить отказ. Незагруженные строки остаются «чистыми» и доступными другим транзакциям для изменения, за исключением «скользящих окон», в которых некоторые незагруженные строки могут быть заблокированы другой транзакцией, даже если блокировка появилась после того, как был запрошен набор данных.

Пример использования WITH LOCK

Приведенный далее оператор определяет неограниченный по количеству строк выходной набор, где каждая строка будет загружаться в буфер на серверной стороне индивидуально. Следующая строка не будет загружаться до тех пор, пока сервер не сообщит о своей готовности ее принять, WITH LOCK пытается выполнить пессимистическую блокировку при запросе каждой строки. Будет возвращена либо следующая строка, либо исключение.

SELECT + FROM DOCUMENT

WHERE PARENT ID=? FOR UPDATE WITH LOCK

Ограничения явной блокировки

Конструкция SELECT … WITH LOCK доступна в DSQL и PSQL. Она может использоваться только в операторе SELECT верхнего уровня для единственной таблицы.

* Она недоступна в подзапросе или в соединяемом наборе.

* Она не может быть указана с квантификаторами (оператор DISTINCT, FIRST или SKIP), С предложением GROUP BY, а также с любыми другими агрегатными операциями.

* Она не может быть использована в просмотрах, во внешних таблицах и в выходном наборе хранимой процедуры выбора.

Хранимые процедуры, триггеры и транзакции

Сведения о написании и использовании хранимых процедур и триггеров см. в части VII.

Хранимые процедуры

Хранимые процедуры выполняются в контексте тех транзакций, которые их вызвали. Сделанная работа, включая ту, которая была выполнена в задачах встроенных или рекурсивных вызовов, будет иметь результат, если все завершится без ошибок, с обработанными исключениями и вся работа будет подтверждена. Если результатом обработки исключения в одной операции будет откат транзакции, то вся работа этой транзакции будет отменена.

Триггеры

Триггеры вызываются внутри контекста оператора DML. Сделанная работа, включая ту, которая была выполнена в задачах встроенных вызовов процедур, все обновления, добавления или удаления данных других таблиц или за счет внутренней ссылочной целостности или другими триггерами, принадлежащими другим таблицам — все будет подтверждено или возвращено клиенту в неопределенном состоянии. Необработанные исключения в одной операции приведут к отмене операции, при которой встретилась ошибка, и сохранят транзакцию в том состоянии, когда приложение сможет принять решение отменить транзакцию или попытаться исправить ошибку и заново отправить запрос. Отмена транзакции отменит все операции, выполненные в транзакции до момента появления исключения.

«Точки сохранения» в PSQL

Добавление возможностей создания пользовательских точек сохранения в Firebird 1.5 позволяет приложению управлять область действия отката транзакции. В PSQL всегда была возможность обработки исключений. Подробности см. в главе 32.

Советы по оптимизации поведения транзакции

Выбор подходящей модели транзакции

Модель «одна транзакция на все приложение» искушает неопытного разработчика игнорировать проблему многопользовательской работы в пользу «простоты программирования». Результатом является такая архитектура приложения, которая плохо работает на всех уровнях: медленные запросы и ответы на обновление списков, перегруженная сеть, не дружественная к пользователю последовательность выполняемых действий и высокий уровень конфликтов.

Не переходите к «общему» пока вам это не понадобилось

Общие интерфейсы приложений для баз данных, такие как ODBC или Borland BDE, объединяют одно соединение с базой данных с одной транзакцией. Поскольку их задачей является скрыть разницу между простенькими, основанными на файлах ре- позиториями данных и сложными, использующими транзакции системами управления базами данных, они не поддерживают возможностей наличия множества активных конкурирующих транзакций в сессии базы данных или транзакций, имеющих доступ к нескольким базам данных.

В лучшем случае эти общие интерфейсы обеспечивают примитивный способ масштабирования простых баз данных или выравнивания разницы между различными реализациями СУБД всевозможных разработчиков. Если вам не нужен такой низкоуровневый общий знаменатель, не используйте их.

Использование возможностей множества транзакций

Клиент Firebird может запустить множество параллельных транзакций. Пользовательская работа с множеством задач в одном приложении может выполнять различные действия с теми же самыми (или перекрывающимися) наборами данных. Модель транзакций Firebird обеспечивает большие преимущества в проектировании, где нужно удовлетворять требованиям модульности в многозадачном окружении в очень чувствительной манере. Важной задачей при создании программного обеспечения являются техники разработки, обеспечивающие сохранение процесса работы и синхронизированного вида состояния базы данных для пользователя.

Сохраняйте передвижение OAT!

Медленное передвижение OAT почти всегда указывает на транзакции, выполняющиеся долго. Исключение таких транзакций является одним из наилучших навыков, которые вы можете получить, обучаясь написанию клиентских приложений для Firebird.

Проще всего обвинить поведение пользователей в появлении долгих транзакций. Вы должны помочь им научиться завершать задачи в разумное время: не отправляться пить кофе, не завершив задач, не выдавать «диких запросов» в пиковое время и т.д. При этом хорошее проектирование клиентского приложения исключает его зависимость от правильного поведения пользователя.

* Подходят механизмы, которые завершают со временем забытые транзакции.

* Как основное правило, исключите интерфейсы просмотра данных и используйте практичные средства.

* Если использование интерфейса просмотра неизбежно, изолируйте операторы, выбирающие данные для просмотра, в транзакциях READ-ONLY READ COMMITTED.

* Убедитесь, что транзакции READ/WRITE регулярно подтверждаются — даже если пользователи используют их только для просмотра данных.

* Избегайте приложений, выполняющих произвольные запросы, включая в запросы WHERE и устанавливая ограничения по времени.

* Убедитесь, что ваши приложения имеют средства для периодического выполнения «жестких подтверждений» любых транзакций, выполняющих COMMIT RETAIN.

* Возьмите за правило использовать RollbackRetaining не более одного раза в обработчике исключений. Не помещайте RollbackRetaining внутрь циклов!

* Учитывайте, что происходит с транзакциями в сервере! Используйте gstat -h или эквивалентный инструмент для отслеживания OIT и OAT. Обращайте внимание на «зазор»^[109].

* Не пренебрегайте наведением порядка в базе данных. Чистка (sweep) должна выполняться систематически. Регулярное выполнение резервного копирования, даже без восстановления базы данных, поможет поддерживать инвентарные страницы транзакций в хорошей форме^[110].

Пора дальше

Теперь, когда вы освоили запутанные вопросы управления транзакциями, самое время направить ваши таланты на программирование на серверной стороне. В части VII вы начнете работать с мощными средствами, доступными в PSQL: хранимые процедуры и триггеры, обработка пользовательских исключений, механизм событий в Firebird. В главе 28 мы начнем рассматривать преимущества действий на стороне сервера для централизации бизнес-правил и сокращения сетевого трафика перед тем, как перейдем к синтаксису и техникам в следующих главах.

ЧАСТЬ VII. Программирование на сервере.

ГЛАВА 28. Введение в программирование в Firebird.

Одним из самых больших преимуществ полнокровных реализаций реляционных баз данных SQL является их способность компилировать и выполнять внутренние модули (хранимые процедуры и триггеры), представленные разработчиками в виде исходных кодов. Язык, который предоставляет такую возможность для сервера Firebird — PSQL — простой, но мощный набор расширений языка SQL, который объединяется с обычными операторами языка манипулирования данными (DML) для создания компилируемых исходных модулей.

Обзор модулей сервера

Языком высокого уровня для программирования в Firebird на стороне сервера является SQL. Исходный код предоставляется серверу в форме расширений языка программирования SQL- операторов и конструктов PSQL- и операторов DML. Сами эти операторы находятся внутри одного оператора DDL вида:

{CREATE | RECREATE | ALTER} {TRIGGER | PROCEDURE} <имя> . . .

. . .

BEGIN

<один или более блоков операторов>

END

Синтаксис написания модулей PSQL подробно рассматривается в следующих главах.

Назначением каждого из этих «супероператоров DDL» является создание и сохранение одного исполняемого модуля (хранимой процедуры или триггера) или переопределение (RECREATE или ALTER) существующего объекта. Оператор DDL также используется для уничтожения (DROP) исполняемых объектов.

PSQL поддерживает три оператора манипулирования данными: INSERT, UPDATE и DELETE и возможность выборки (SELECT) одной строки или многострочных наборов элементов данных с помещением в локальные переменные. Расширения PSQL обеспечивают перечисленную далее языковую и логическую поддержку.

* Локальные переменные и операторы присваивания.

* Условные операторы управления потоком выполнения.

* Специальные контекстные переменные (только для триггеров) для доступа к старому и новому значению каждого столбца во всех входных наборах DML.

* Отправка определенных пользователем событий базы данных прослушивающим клиентам.

* Исключения, в том числе определенные пользователем, объявленные как объекты базы данных, а также (в версии 1.5) специфичные для контекста сообщения об исключениях, поддержка структуры и синтаксиса для обработки ошибок.

* Входные и выходные аргументы (только для хранимых процедур).

* Инкапсуляция поведения курсора в синтаксисе цикла FOE SELECT … INTO … DO.

* Оператор SUSPEND (только для хранимых процедур), предоставляющий возможность написания хранимых процедур, которые выводят виртуальную таблицу на запрос в операторе SELECT — хранимые процедуры выбора.

* Внутренние вызовы хранимых процедур в хранимых процедурах и триггерах.

* Возможность определения множества триггеров для фаз BEFORE (до) и AFTER (после) в триггерах для каждого события DML и задание их позиции в предварительно определенном порядке их исполнения. В версии 1.5 появилась возможность писать условные триггеры BEFORE и AFTER, объединяющие любые из всех возможных событий DML.

За исключением указанных специфических элементов все множество языка PSQL доступно для хранимых процедур и триггеров.

Хранимые процедуры

Хранимые процедуры могут быть использованы в приложениях различными способами.

* Процедуры выбора используются на месте таблицы или просмотра в операторе

SELECT.

* Выполняемые процедуры исполняются оператором EXECUTE PROCEDURE для выполнения одной операции или запуска множества операций на стороне сервера.

* Хранимая процедура может быть вызвана из другой хранимой процедуры или из триггера. Она может вызывать сама себя рекурсивно.

Все хранимые процедуры определяются в сложном операторе DDL CREATE PROCEDURE. Объявления выполняемых хранимых процедур и хранимых процедур выбора следуют одним и тем же синтаксическим правилам. Необязательные языковые элементы отличаются для процедур выбора и выполняемых процедур. Одна процедура может быть вложенной в другую, каждая из которых выполняет часть атомарной последовательности работы, которая будет подтверждена клиентским приложением как единое целое или отменена как целое.

Преимущества использования хранимых процедур

Перечислим преимущества использования процедурных модулей, которые выполняются внутри базы данных.

* Модульное проектирование: все приложения, имеющие доступ к одной базе данных, совместно используют хранимые процедуры, что, следовательно, централизует бизнес-правила, позволяет повторно использовать код, сокращает размер приложений.

* Хорошо налаженная поддержка: когда процедура модифицируется, изменения автоматически распространяются на все приложения без необходимости дальнейшей перекомпиляции на стороне приложения, за исключением изменений, влияющих на наборы входных или выходных аргументов.

* Улучшенное выполнение: выполнение сложной обработки делегируется серверу, сокращая сетевой трафик и нагрузки оперирования с внешними наборами.

* Экономия в архитектуре: клиентские приложения могут сфокусироваться на получении входных данных от пользователя и на управлении интерактивными задачами, в то время как серверу, который предназначен для управления данными, делегируется управление сложными данными и их зависимостями.

* Дополнительная функциональность: искусный доступ к данным, который не может быть достигнут средствами обычного SQL, может быть выполнен одной или группой хранимых процедур.

Триггеры

Триггер является подпрограммой, связанной с таблицей или просмотром, которая автоматически выполняет некоторые действия, когда строка таблицы или просмотра добавляется, изменяется или удаляется.

Триггер никогда не вызывается напрямую. Когда приложение или пользователь пытается выполнить INSERT, UPDATE или DELETE для строки таблицы, триггеры, связанные с этой таблицей, вызываются автоматически. Триггеры могут использовать исключения и события. Они также могут вызывать хранимые процедуры.

Триггеры являются мощным инструментом в различных вариантах использования. Перечислим способы использования триггеров.

* Для выполнения коррелированных изменений при выполнении оператора DML с таблицей. Например, триггер может добавлять записи во внутренний или внешний протокол изменений. Триггер AFTER DELETE (после удаления) может добавить строку в таблицу истории.

* Для проверки исходных данных.

* Для преобразования данных, например, для автоматического конвертирования входного текста в буквы верхнего регистра или для получения значения автоинкрементного ключа из генератора.

* Для информирования приложений об изменениях базы данных с использованием средств сообщения о событиях (event alerter).

* Для выполнения пользовательских каскадных изменений целостности данных.

* Чтобы сделать просмотр только для чтения изменяемым. Подробности см. в разд. «Преобразование просмотров только для чтения в изменяемые»главы 24.

Триггеры хранятся как объекты базы данных так же, как хранимые процедуры и исключения. Объявленные как ACTIVE, они остаются активными, пока не будут деактивированы оператором ALTER TRIGGER или удалены из базы данных с помощью DROP TRIGGER.

Триггер никогда не вызывается явно — активный триггер выполняется автоматически, когда заданная операция DML выполняется для его таблицы.

Преимущества использования триггеров

Перечислим преимущества использования триггеров.

* Автоматическое применение ограничения данных, чтобы убедиться, что пользователи вводят только допустимые значения в столбцы.

* Сокращение объема поддержки приложений, поскольку изменения триггеров автоматически отражаются на всех приложениях, которые используют связанные таблицы, без необходимости их повторной компиляции и сборки.

* Автоматическое протоколирование изменений таблиц. Приложение может использовать протоколирование изменений с помощью триггера, который вызывается при модификации таблицы.

* Автоматическое информирование об изменениях базы данных с помощью средств сообщения о событиях.

Триггеры в качестве автоинкрементного механизма

Триггеры могут быть использованы в комбинации с генераторами для реализации автоинкрементных ключей. Подробные инструкции вы можете найти в главе 31.

Триггеры и транзакции

Триггеры всегда выполняются в контексте конкретной операции DML, как часть этой операции и внутри той транзакции, которая осуществляет запрос оператора DML. Нет смысла отделять их от транзакции или от операции, которая привела к выполнению триггера. Если транзакция будет отменена, то и все действия, выполненные триггером, также будут отменены.

Расширения языка PSQL

Расширения языка PSQL включают следующие языковые элементы:

* операторы BEGIN и END для выделения блоков кода, которые могут быть вложенными;

* операторы DECLARE VARIABLE для объявления локальных переменных;

* конструкция FOR SELECT <спецификация-выбора> INTO <список-переменных? DO инкапсулирует курсор SQL для выполнения цикла просмотра наборов. Циклы могут быть вложенными;

* циклы WHILE;

* оператор SUSPEND для пересылки строки в кэш строк;

* конструкция IF … THEN и ELSE для ветвления в программе;

* оператор EXCEPTION <объявленное-имя-исключения> для вызова пользовательских исключений;

* необязательные блоки WHEN <условие-исключения> DO для перехвата и обработки исключений;

* POST_EVENT <строка> для передачи сообщений клиентам.

Firebird версии 1.5 и более поздние также поддерживает:

* оператор EXECUTE STATEMENT для выполнения специальных операторов DML и DDL в модуле;

* логические контекстные переменные UPDATING, INSERTING и DELETING;

* контекстная переменная ROW_COUNT для получения количества строк, полученных выполненным оператором DML в том же блоке;

* дополнительный синтаксис для EXCEPTION без аргументов — для повторного вызова исключений, а с необязательным текстовым аргументом — для передачи информации клиенту.

Ограничения PSQL

Существуют некоторые ограничения языка для кодов в модулях PSQL.

* Операторы, использующие подмножество языка определения данных (DDL) SQL Firebird, не разрешены в PSQL^[111].

* Операторы управления транзакциями недопустимы в PSQL, потому что хранимые процедуры и триггеры всегда выполняются в контексте существующей клиентской транзакции, a Firebird не поддерживает вложенные транзакции.

* Некоторые другие типы операторов, зарезервированные для использования в других средах (например, в isql, скриптах или во встроенном SQL — см. следующий раздел). Допустимы все динамические операторы DML.

* Идентификаторы объектов метаданных, такие как имена таблиц, столбцов, просмотров или хранимых процедур, не могут передаваться хранимой процедуре или возвращаться хранимой процедурой в ее аргументах.

* Триггеры не могут получать или возвращать аргументы.

Типы операторов, не поддерживаемых в PSQL

Следующие типы операторов не поддерживаются в триггерах и хранимых процедурах:

* операторы языка определения данных (т. е. операторы, начинающиеся с ключевых слов CREATE, RECREATE, ALTER или DROP; SET GENERATOR; DECLARE EXTERNAL FUNCTION: DECLARE FILTER);

* операторы управления транзакциями: SET TRANSACTION, COMMIT, COMMIT RETAIN,

ROLLBACK, SAVEPOINT, RELEASE SAVEPOINT, ROLLBACK TO SAVEPOINT;

* операторы ESQL: PREPARE, DESCRIBE, EXECUTE;

* операторы CONNECT/DISCONNECT и отправки операторов SQL другим базам данных;

* GRANT/REVOKE;

* EVENT INIT/EVENT WAIT;

* BEGIN DECLARE SECTION/END DECLARE SECTION;

* BASED ON;

* WHENEVER;

* DECLARE CURSOR;

* OPEN;

* FETCH;

* любые операторы, начинающиеся с ключевых слов SET и SHOW.

Исключения

Обработчики исключений могут быть написаны, чтобы «съесть» ошибку, обрабатывая ее разными способами. Например, в итеративной подпрограмме входная строка, вызывающая исключение, необязательно должна приводить к остановке всего процесса. Обработка исключения внутри триггера или хранимой процедуры может позволить пропустить проблемную входную строку — например, поместив сообщение об ошибке в протокол в текстовый файл или в таблицу ошибок — и дав возможность продолжить дальнейшую обработку.

Код в модуле может обрабатывать ошибку в необязательном фрагменте кода, называемом блоком исключения, который является последовательностью операторов, заключенных в операторные скобки BEGIN и END, которым предшествует ключевое слово WHEN.

Необработанное исключение останавливает процесс, отменяет всю выполненную к этому

моменту работу^[112] и возвращает сообщение об ошибке приложению. Вы также можете написать код, вызывающий пользовательское исключение и останавливающий процесс. Вы можете обработать эту ошибку в вашем коде или остановить процесс и вернуть пользовательское сообщение клиентскому приложению. Если модуль является триггером, то операция DML, в которой появилась эта ошибка, также будет отменена. В базе данных вы можете создать столько пользовательских исключений, сколько вам нужно. Начиная с версии 1.5, вы можете использовать данные времени выполнения и конструировать тексты для ваших сообщений об исключениях «на лету».

Обработка исключений и ошибок подробно обсуждается в главе 32.

События

События Firebird являются «сигналами», которые модули PSQL могут накапливать в процессе выполнения для передачи клиентским приложениям, когда работа будет подтверждена. Клиентские приложения в сети могут прослушивать- с использованием обработчика сообщений- конкретные события, в которых они заинтересованы, без необходимости специального опроса наличия события.

Программирование с событиями и задание приложениям указания на их прослушивание рассматривается в главе 32.

Безопасность

Процедурам и триггерам могут быть предоставлены привилегии для специфических действий (SELECT, INSERT, DELETE и т.д.) к таблицам точно так же, как пользователям или ролям предоставляются привилегии. Не существует специального синтаксиса: используется обычный оператор GRANT, но в предложении то указывается триггер или процедура вместо пользователя или роли. Аналогичным образом привилегии процедур и триггеров могут отменяться оператором REVOKE.

Не всегда существует необходимость предоставлять привилегии модулям процедур или триггеров. Достаточно либо пользователю, либо модулю иметь привилегии к действиям, выполняемым модулем.

Например, если пользователь выполняет UPDATE для таблицы А, что вызывает триггер, а триггер выполняет INSERT для таблицы в, то это действие будет допустимым, если пользователь имеет привилегии INSERT к этой таблице или триггер имеет привилегии INSERT к этой таблице.

Если у триггера или процедуры нет достаточных привилегий для выполнения их действий, Firebird вызывает ошибку SQL и устанавливает соответствующий код ошибки. Вы можете перехватить этот код ошибки в обработчике исключений точно так же, как и другие исключения. Информацию об операторах GRANT и REVOKE см. в главе 35.

Внутреннее устройство технологии

Когда любой запрос вызывает хранимую процедуру, то текущее определение этой хранимой процедуры копируется в этот момент в кэш метаданных. В Классическом сервере эта копия присутствует в течение всего времени пользовательского соединения. В Суперсервере она сохраняется «живой», пока не будет отключено последнее соединение.

Запрос приходит от одного из следующих объектов:

* от клиентского приложения, которое напрямую выполняет хранимую процедуру;

* от триггера, который выполняет хранимую процедуру. Сюда относятся и системные триггеры, являющиеся частью систем поддержания ссылочной целостности или ограничений CHECK;

* от другой хранимой процедуры, которая выполняет эту хранимую процедуру.

Эффекты изменений

Однажды вызванный запрос к триггеру или хранимой процедуре сохраняется в кэше метаданных, пока существуют клиентские соединения с базой данных, независимо от того, использует ли какой-нибудь клиент этот триггер или хранимую процедуру. Не существует механизма убрать эти невыполняющиеся запросы из кэша метаданных. По этой причине изменения модулей PSQL являются «отложенными» в большей или меньшей степени в большинстве случаев. Возможность для клиентов видеть эти изменения отличается для Классического сервера и Суперсервера.

Суперсервер

Поскольку существующие запросы удаляются из кэша метаданных только тогда, когда последний клиент отключится от базы данных, они вообще никогда не будут обновлены в системах 24/7 (т. е. в системах, работающих 24 часа в сутки и 7 дней в неделю). Существует только один способ гарантировать, что все копии хранимых процедур и триггеров будут удалены из кэша метаданных — завершение всех соединений с базой данных. Когда пользователи снова соединятся с базой данных, они все увидят новые версии хранимых процедур и триггеров.

Классический сервер

Изменение или удаление хранимой процедуры немедленно воздействует на новые соединения, осуществляемые после подтверждения изменения. Новые соединения, которые вызывают хранимую процедуру, увидят самую последнюю версию. При этом другие соединения продолжают видеть ту версию хранимой процедуры, которую они видели с самого начала соединения. С точки зрения практики имеет смысл отключить всех клиентов до подтверждения изменений таких модулей.

Пора дальше

Теперь мы рассмотрим структуру модулей PSQL: что общего имеют триггеры и процедуры и чем они отличаются.

ГЛАВА 29. Разработка модулей PSQL.

Хранимые процедуры и триггеры объявляются при помощи операторов CREATE PROCEDURE и CREATE TRIGGER соответственно. Каждый из этих сложных операторов состоит из заголовка и тела.

Элементы процедур и триггеров

Определения модулей PSQL действительно являются одним оператором SQL, который начинается предложением CREATE и завершается терминатором. В определении модуля существует множество элементов: предложений, ключевых слов, блоков множества элементов, программных ветвей, циклов и др. Одни элементы являются обязательными, другие необязательными.

Хотя комплекс объявлений модуля PSQL является оператором DDL, расширения SQL в этом комплексе являются элементами структурированного языка высокого уровня, который имеет особые правила. Одним из этих правил, которое вы должны знать до начала работы, является использование терминатора оператора.

Оператор CREATE

Исходный код процедуры и триггера конструируется внутри «супероператора», который начинается с ключевых слов CREATE PROCEDURE или CREATE TRIGGER и завершается символом терминатора, следующим за конечным оператором END, например:

CREATE PROCEDURE ИМЯ . . .

. . .

BEGIN

. . .

END ^

В хранимых процедурах и триггерах все операторы, следующие за ключевым словом AS, включают локальные переменные (если присутствуют) и логику программного модуля. Основное различие между триггерами и хранимыми процедурами заключается в заголовке оператора CREATE (СМ. рис. 29.1).

Терминатор операторов

Каждый оператор внутри тела хранимой процедуры или триггера- кроме BEGIN и END- должен заканчиваться точкой с запятой. Никакой другой символ не является допустимым терминатором операторов в PSQL. В DSQL для операторов DML и DDL в Firebird точка с запятой также является терминатором по умолчанию. Она также является стандартом SQL для завершения операторов.

Такая ситуация может создать логическую проблему для синтаксического анализатора, который выполняет предварительную компиляцию наших модулей PSQL: какая точка с запятой завершает операторы внутри модуля, а какая завершает определение CREATE?

Чтобы обойти эту проблему, в Firebird есть синтаксис переключения SET TERM, который позволяет вам устанавливать другой внешний терминатор, который воздействует на внешние операторы, в то время как синтаксический анализатор обрабатывает определения PSQL. В скриптах опытные разработчики часто используют одиночный оператор SET TERM в начале каждого скрипта, чтобы использовать свой любимый альтернативный терминатор в течение всего времени выполнения скрипта. Некоторые инструменты администратора баз данных поддерживают средства конфигурирования альтернативных терминаторов в своих редакторах и программах выделения метаданных.

Операторы SET TERM используются в isql и в скриптах.

Утилита isql предварительно анализирует каждый оператор и отправляет любой завершенный терминатором оператор на сервер в виде одной команды, SET TERM является одним из собственных операторов ISQL, который используется не для пересылки запроса на сервер, а для подготовки собственного синтаксического анализатора для различной интерпретации терминаторов. (Другие операторы SET В ISQL также вызывают специальные действия в программе isql, которые не имеют значения вне isql.)

DSQL совсем не распознает терминаторы операторов. Большинство других утилит, выполняющих скрипты, отправляют операторы DDL на сервер один за другим без терминаторов. Они выполняют свой собственный синтаксический анализ для распознавания начала и завершения операторов CREATE PROCEDURE и передают внутренние терминаторы точка с запятой просто как обычные символы синтаксиса составного оператора.

Когда вы используете такую утилиту для интерактивного создания модулей PSQL, она обычно выдает исключение на оператор SET TERM, потому что как оператор SQL он не имеет смысла за пределами isql. При этом в скриптах эти утилиты обычно обрабатывают оператор SET TERM и внутренне используют альтернативный терминатор так же, как и утилита isql.

Таким образом, включайте оператор SET TERM В isql, если вы используете этот инструмент интерактивно, а также включайте его в скрипты.

Альтернативный терминатор может быть любой, нравящейся вам строкой символов, за исключением точки с запятой, пробела и апострофа. Если вы используете буквенный символ, он будет чувствительным к регистру. Если вам так нравится, можете задать терминатор, содержащий несколько символов, включая пробелы; он только не может быть зарезервированным ключевым словом. Оба следующих оператора допустимы:

SET TERM ^

SET TERM boing! ;

! ! !

СОВЕТ. He будьте только слишком изобретательными при создании ваших строк терминаторов, иначе вам придется набирать большой текст!

. ! .

В определениях PSQL применяйте точку с запятой во всех внутренних операторах за исключением BEGIN и END и используйте альтернативный терминатор в конечном операторе END:

. . .

END ^

Для возврата к «нормальному» оператору терминатора выдайте второй оператор SET TERM, который изменит результат первого:

. . .

END ^

COMMIT ^

SET TERM ;^

Рис. 29.1. Обязательные элементы в определении модуля PSQL

На рис. 29.1 основные элементы определения модуля PSQL отделены для иллюстрации требуемых элементов в секциях HEADER (Заголовок) и BODY (Тело) модуля.

Обязательные части затенены.

Элементы заголовка

Имя процедуры или триггера должно быть уникальным в базе данных.

Для триггера:

* ключевое слово FOR и ИМЯ таблицы идентифицируют ту таблицу, операции с которой вызывают данных триггер;

* режим (ACTIVE или INACTIVE);

* параметр фазы (BEFORE или AFTER) определяет, когда вызывается триггер;

* параметр события (INSERT, UPDATE, DELETE)^[113];

* необязательное ключевое слово POSITION, за которым следует целое число, указывающее последовательность вызова.

Для хранимой процедуры:

* необязательный список входных параметров и их типов данных;

* если процедура возвращает значения вызвавшей программе, то список выходных параметров и их типов данных.

Элементы тела

Для хранимых процедур и триггеров:

* тело модуля может начинаться со списка из одного или более объявлений локальных переменных (имя и тип данных SQL — домен указывать нельзя);

* блок операторов на языке процедур и триггеров Firebird, заключенный в операторные скобки BEGIN и END. Блок сам может включать другие блоки, следовательно, может существовать много уровней вложенности;

* некоторые встроенные блоки могут быть обработчиками исключений, возникающих в предшествующих блоках. Такие блоки являются условными в соответствии с предшествующим предикатом WHEN. Модуль глобальных обработчиков исключений должен предшествовать всем встроенным блокам.

Элементы языка

В табл. 29.1 показаны элементы языка PSQL, доступные в Firebird.

Таблица 29.1. Расширения PSQL для хранимых процедур и триггеров

Оператор	Описание	В. 1.5	В. 1.0.x
BEGIN … END	Определяет блок операторов, которые выполняются как одно целое. Зарезервированное слово BEGIN начинает блок; зарезервированное слово END завершает его. Ни за одним из них не должна следовать точка с запятой. В версии 1.0.x нельзя выдать оператор CREATE PROCEDURE без хотя бы одного оператора между BEGIN и END. «Пустые» определения допустимы в версии 1.5 и выше	Да	Да
переменная = выражение	Присваивает значение выражения переменной- локальной переменной, входному параметру или выходному параметру	Да	Да
/* текст комментария */	Комментарий программиста, где текст может содержать любое количество строк между парой /* */. Может быть также использован для встроенных комментариев	Да	Да
— текст комментария	Комментарий программиста из одной строки, где текст может быть встроенным (только версия 1.5) или может занимать одну строку, где маркер двойного минуса (-) является первым элементом в строке	Да	Да
EXCEPTION имя-исключения	Вызывает именованное исключение для возможной обработки в блоке WHEN. Само исключение должно быть предварительно определено администратором базы данных с использованием CREATE EXCEPTION	Да	Да
EXCEPTION	Вызывает исключение	Да	Нет
EXCEPTION имя-исключения сообщение-времени-выполнения	Вызывает именованное исключение и присоединяет к нему сообщение времени выполнения — локальную переменную типа VARCHAR, которой во время выполнения может быть присвоено значение. Подробности определения и использования исключений см. в главе 32	Да	Нет
EXECUTE PROCEDURE имя-процедуры [переменная [, переменная …]] [ RETURNING_VALUES переменная [, переменная. . .]]	Выполняет хранимую процедуру имя- процедуры. Входные аргументы следуют за именем процедуры; возвращаемые значения следуют за ключевым словом RETURNING VALUES. Допустимы вложенные процедуры и рекурсия. Входные и выходные параметры должны быть переменными, определенными в процедуре	Да	Да
EXECUTE STATEMENT <строка>	Выполняет оператор динамического SQL, содержащийся в <строка>	Да	Нет
EXIT	Переходит на конечный оператор END. Необязателен	Да	Да
FOR … SELECT … INTO … DO	Синтаксис составного блока цикла для обработки неявного курсора и (необязательной) генерации виртуальной таблицы для направления выхода запроса SELECT клиенту. Подробности см. в разд. «SELECT для множества строк»	Да	Да
IF . . . THEN .. . [ELSE] …	Синтаксис составного ветвления. Подробности см. в разд. «Условные блоки» позже в этой главе	Да	Да
LEAVE^[114]	Оператор не принимает параметров. Используется для выхода из цикла. Выполнение переходит к первому оператору, следующему за концом того блока, который включает цикл, где был выполнен оператор LEAVE	Да	Нет
NEW. имя-столбца	Только триггеры. Контекстные переменные, доступные для триггеров INSERT и UPDATE. Существует одна переменная NEW для каждого столбца таблицы, содержащая новое значение, передаваемое клиентским запросом. Также доступна в некоторых ограничениях CHECK. Заметим, что в версии 1.5 в триггерах для нескольких действий ссылка на NEW. переменная не является ошибкой, поскольку она вернет NULL, если используется в контексте удаления	Да	Да
OLD.имя-столбца	Только триггеры. Контекстные переменные, доступные для триггеров INSERT и DELETE. Существует одна переменная OLD для каждого столбца таблицы, содержащая значение, которое имел столбец до выдачи клиентского запроса. Также доступна в некоторых ограничениях CHECK. Заметим, что в версии 1.5 в триггерах для нескольких действий ссылка на OLD.переменная не является ошибкой, даже если триггер включает действия по добавлению данных. Она вернет NULL, если используется в контексте добавления	Да	Да
POST_EVENT имя-события	Помещает событие имя-события в стек. Имя события может быть произвольной строкой длиной до 78 символов и не является предварительно определенным на сервере. События из стека будут переданы клиентам, «прослушивающим» это событие через обработчик сообщений. Подробности см. в разд. «События» главы 32	Да	Да
SELECT … INTO …	Помещает выход обычного одиночного оператора SELECT в список предварительно объявленных переменных. Вызовет исключение, если оператор вернет множество строк	Да	Да
SUSPEND	Недоступен в триггерах! Оператор используется в процедурах, разработанных для вывода наборов множества строк в виде виртуальных таблиц — хранимые процедуры выбора. Он приостанавливает выполнение процедуры на время перемещения строки из кэша строк в клиентское приложение. Оператор не имеет этого эффекта в выполняемых хранимых процедурах, где он эквивалентен оператору EXIT	Да	Да
WHILE <условие> DO	Синтаксис условного цикла, при котором выполняется блок, пока условие не станет ложным. Подробности см. в разд. «Условные блоки» позже в этой главе	Да	Да
WHEN {ошибка [, ошибка . . . ] \| ANY}	Синтаксис для обработки исключений. Аргументами могут быть одно или более определенных пользователем исключений или внутренне определенные исключения GDSCODE или SQLCODE. Подробности см. В главе 32	Да	Да

Программные конструкции

В следующих разделах рассматриваются программные конструкции, распознаваемые в PSQL.

Блоки BEGIN … END

PSQL является структурированным языком. После объявления переменных процедурные операторы заключаются в операторные скобки BEGIN и END. В процессе разработки логики процедуры могут быть добавлены другие блоки; любой блок может включать другой блок, заключенный в BEGIN и END.

Символ терминатора не используется в ключевых словах BEGIN и END, за исключением финального ключевого слова END, который закрывает процедурный блок и завершает оператор CREATE PROCEDURE или CREATE TRIGGER. Это финальное ключевое слово END имеет специальный терминатор, который был определен в операторе SET TERM до начала данного определения.

Условные блоки

PSQL распознает два типа условных структур:

* ветвление, управляемое блоками IF … THEN И, возможно, ELSE;

* циклическое выполнение блока, пока условие WHILE не станет ложным.

Начиная с версии 1.5 логические контекстные переменные INSERTING, UPDATING и DELETING и целочисленная контекстная переменная ROW_COUNT доступны в качестве предикатов в блоках, выполняющих операции изменения состояния данных. Подробности использования логических контекстных переменных в триггерах для множества событий см. в главе 31.

Конструкция IF… THEN… ELSE

Конструкция IF … THEN … ELSE осуществляет ветвление в программе, проверяя указанное условие. Синтаксис:

IF (<условие>)

THEN <составной-оператор>

[ELSE <составной-оператор>]

<составной-оператор> = {<блок><оператор>;}

Предложение условие является предикатом, который должен быть истинным, чтобы выполнился оператор или блок, следующий за THEN. Необязательное предложение ELSE задает альтернативный оператор или блок, который будет выполняться, если условие окажется ложным. Условие может быть любым правильным предикатом.

! ! !

ПРИМЕЧАНИЕ. Предикат, проверяемый в IF, должен быть заключен в скобки.

. ! .

Когда вы кодируете условный переход в SQL, использование предложения ELSE иногда бывает необходимым для «нейтрализации» в случаях, когда проверяемый в IF предикат может не иметь ни истинного, ни ложного значения. Такое может произойти, когда в предикате во время выполнения сравниваются два пустых (NULL) значения. Логические значения истина и ложь являются в этом случае невозможными. Ветвь ELSE в этом случае является гарантией, что ваш блок выдаст результат.

Следующий фрагмент кода иллюстрирует использование IF … ELSE в предположении, что FIRST_NAME, LAST_NAME, и LINE2 были ранее объявлены как переменные или аргументы:

. . .

IF (FIRST_NAME IS NOT NOLL) THEN

LINE2 = FIRST_NAME || ‘ ‘ || LAST_NAME;

ELSE

BEGIN

IF (LAST_NAME IS NOT NULL) THEN

LINE2 = LASTNAME;

ELSE

LINE2 = ‘NO NAME SUPPLIED’;

END

. . .

! ! !

СОВЕТ. Программисты языка Pascal, заметьте, что IF … THEN завершен терминатором!

. ! .

По поводу CASE

Пока PSQL не поддерживает логику CASE В качестве конструкции программирования. Логика выражения CASE, конечно, доступна в DSQL. Подробности см. в главе 21.

Конструкция WHILE… DO

WHILE … DO является конструкцией цикла, который повторяет оператор или блок операторов, пока условие является истинным. Условие проверяется в начале каждого цикла, WHILE … DO использует следующий синтаксис:

. . .

WHILE (<условие>) DO

BEGIN

<выполнение одного или более операторов>

<изменение значения операнда в условии> ;

END

/* Здесь продолжение выполнения */

. . .

В следующей простой процедуре WHILE проверяет значение переменной i, которая инициализируется как входной аргумент. Блок цикла уменьшает значение i при каждой итерации, и пока i остается больше нуля, значение выходного параметра r увеличивается на значение i. Когда процедура завершается, значение r возвращается вызвавшему приложению.

SET TERM ^;

CREATE PROCEDURE MORPH_ME (i INTEGER) RETURNS (r INTEGER)

BEGIN

r = 0;

WHILE (i > 0) DO

BEGIN

r = r + i;

i = i — 1;

END

END^

Вызов процедуры из isql:

SQL> EXECUTE PROCEDURE MORPH_ME (16) ;

Мы получаем:

========

136

Переменные

Пять типов переменных может быть использовано в теле модуля с некоторыми ограничениями в соответствии с тем, является модуль хранимой процедурой или триггером.

* Локальные переменные для хранения значений используются только в триггерах и хранимых процедурах.

* Контекстные переменные NEW.имястолбца и OLD.имястолбца ограничены использованием в триггерах; они хранят новые и старые значения каждого столбца таблицы, когда оператор DML ожидает завершения.

* Другие контекстные переменные, специфичные в PSQL, также доступны в isql и PSQL.

* Входные аргументы используются для передачи значений хранимым процедурам из клиентских приложений, других хранимых процедур и триггеров. Недоступны в триггерах.

* Выходные аргументы используются для возвращения значений из хранимых процедур вызвавшим их объектам. Недоступны в триггерах.

Любой из этих типов переменных может быть использован в теле хранимой процедуры везде, где может появиться выражение. Им может присваиваться значение литерала или значения, полученного из запроса или в результате вычисления выражения.

Использование доменов

Поскольку определение доменов потенциально может быть изменено, они не могут быть использованы на месте собственных типов данных SQL при объявлении переменных и аргументов хранимых процедур. Модули PSQL компилируются в двоичную форму во время их создания, и изменения доменов разрушат их, если допустить использование доменов.

Маркер двоеточия (:) для переменных

В операторах SQL задавайте для имен переменных префикс в виде двоеточия (:), когда:

* переменная используется в операторе SQL;

* переменная получает значение в конструкции [FOR] SELECT … INTO.

Опускайте двоеточие во всех других ситуациях.

! ! !

ПРИМЕЧАНИЕ. Никогда не задавайте префикс двоеточия для контекстных переменных.

. ! .

Операторы присваивания

Процедура присваивает значения переменным с использованием синтаксиса:

переменная = выражение;

выражение может быть любой допустимой комбинацией переменных, операторов и выражений, оно может содержать вызовы внешних функций (UDF) и функций SQL, включая функцию GEN_IDO для увеличения и получения значения генератора.

Следующий фрагмент кода выполняет некоторые присваивания:

. . .

WHILE (SI < 9) DO

BEGIN

SI = SI + 1; /* арифметическое выражение */

IF (SUBSTRING(SMONTH FROM 1 FOR 1) = ‘R’) THEN

BEGIN

RESPONSE = ‘YES’; /* простая константа */

LEAVE;

END

SMONTH = SUBSTRING(SMONTH FROM 2); /* функциональное выражение */ END

. . .

Переменным и аргументам должны присваиваться значения того типа данных, с каким они были объявлены. Числовым переменным должны присваиваться числовые значения, а строковым — строковые значения. Хотя Firebird и выполняет автоматическое преобразование типов в некоторых случаях, желательно использовать явное преобразование, чтобы избежать непредвиденных несоответствий типов.

Более подробную информацию о явном преобразовании и о конвертировании типов данных см. в главах 8 и 21.

Локальные переменные

Локальные переменные объявляются, каждая в отдельной строке, до первого оператора BEGIN. Они не имеют значения вне хранимой процедуры или триггера, их область действия не распространяется на другие вызываемые процедуры. Они должны быть объявлены до их использования.

Вам следует всегда инициализировать ваши переменные насколько возможно раньше в вашей процедуре. В Firebird 1.5 вы можете объявлять и инициализировать переменную в одном операторе. Например, каждый следующий оператор допустим для объявления переменной вида счетчик и инициализации ее нулем:

. . .

DECLARE VARIABLE COUNTER1 INTEGER DEFAULT 0;

DECLARE VARIABLE COUNTER2 INTEGER = 0;

Примеры использования локальных переменных

Следующая процедура иллюстрирует фрагмент австралийской шутки о правильности пословицы: «Никогда не ешь свинину, если в названии месяца есть буква R». Она возвращает мнение по поводу полученной даты. Для иллюстрации в ней объявляется одна локальная переменная, которая используется для получения стартового условия для цикла WHILE, и другая — для управления количеством повторов цикла.

CREATE PROCEDURE IS_PORK_SAFE (CHECK_MONTH DATE)

RETURNS (RESPONSE CHAR(3))

DECLARE VARIABLE SMONTH VARCHAR(9);

DECLARE VARIABLE SI SMALLINT;

BEGIN

SI = 0;

RESPONSE = ‘ NO’

SELECT

CASE (EXTRACT (MONTH FROM :CHECK MONTH) )

WHEN 1 THEN ‘JANUARY’

WHEN 2 THEN ‘ FEBRUARY’

WHEN 3 THEN ‘MARCH’

WHEN 4 THEN ‘APRIL’

WHEN 5 THEN ‘MAY’

WHEN 6 THEN ‘JUNE’

WHEN 7 THEN ‘ JULY’

WHEN 8 THEN ‘AUGUST’

WHEN 9 THEN ‘SEPTEMBER’

WHEN 10 THEN ‘OCTOBER’

WHEN 11 THEN ‘NOVEMBER’

WHEN 12 THEN ‘DECEMBER’

END

FROM RDB$DATABASE

INTO :SMONTH;

WHILE (SI < 9) DO

BEGIN

SI = SI + 1;

IF (SUBSTRING(SMONTH FROM 1 FOR 1) = ‘R’) THEN

BEGIN

RESPONSE = ‘YES’;

LEAVE;

END

SMONTH = SUBSTRING(SMONTH FROM 2);

END

END ^

COMMIT ^

SET TERM;^

Можно ли автору есть свинину в ее день рождения?

EXECUTE PROCEDURE IS_PORK_SAFE (‘2004-05-16’);

RESPONSE

=========

! ! !

СОВЕТ. Если бы это была серьезная процедура, в SQL есть более быстрый способ получения того же результата. Например, вместо цикла WHILE вы можете просто проверить переменную SMONTH:

IF (SMONTH CONTAINING ‘R’) THEN RESPONSE = ‘YES’ ELSE RESPONSE = ‘NO’

Вероятно, вы захотите использовать внешнюю функцию для получения названия месяца. В версии 1.5 вы можете инициализировать переменные при их объявлении.

. ! .

Входные аргументы

Входные аргументы (также называемые параметрами) используются для передачи значений от приложения процедуре или от одного модуля PSQL другому. Они объявляются списком в скобках следом за именем процедуры и отделяются друг от друга запятыми. Один раз объявленные, они могут использоваться в теле процедуры везде, где могут появиться выражения.

Например, следующий фрагмент процедуры определяет один входной параметр, чтобы сообщить процедуре, какая страна должна отыскиваться:

CREATE PROCEDURE SHOW_JOBS_FOR_COUNTRY (

COUNTRY VARCHAR(15))

. . .

Входные параметры передаются от вызывающей программы хранимой процедуре по значению. Это означает, что если процедура изменит значение входного параметра, это изменение будет иметь эффект только в процедуре. Когда управление возвращается вызвавшей программе, входной параметр в любом случае будет иметь первоначальное значение.

Входные аргументы недопустимы в триггерах.

Выходные аргументы

Выходной аргумент (параметр) используется для задания значения, возвращаемого из процедуры вызвавшему приложению или модулю PSQL. Если задается множество возвращаемых значений, объявляйте эти аргументы в скобках, отделяя их друг от друга запятыми, следом за ключевым словом RETURNS В заголовке процедуры. Один раз объявленные, они могут использоваться в теле процедуры везде, где могут появиться выражения.

Следующий код завершает определение процедуры, представленной предыдущим фрагментом. Он определяет три элемента данных для возвращения в виде виртуальной таблицы вызвавшему модулю:

CREATE PROCEDURE SHOW_JOBS_FOR_COUNTRY (

COUNTRY VARCHAR (15) )

RETURNS (

CODE VARCHAR (11) ,

TITLE VARCHAR (25) ,

GRADE SMALLINT)

BEGIN

FOR SELECT JOB_CODE, JOB_TITLE, JOB_GRADE FROM job

WHERE JOB_COUNTRY = : COUNTRY

INTO :CODE, :TITLE, :GRADE

BEGIN /* начало цикла */

CODE = ‘CODE: ‘ || CODE;

/* дает немного информации о значении */

SUSPEND; /* выводит одну строку цикла */

END

END ^

Если вы объявляете выходные параметры в заголовке процедуры, процедура должна присвоить им значения, чтобы вернуть их вызвавшему приложению. Значения могут быть получены из любого допустимого выражения в процедуре.

! ! !

СОВЕТ. Всегда инициализируйте выходные параметры до начала обработки данных, которые могут быть присвоены параметрам.

. ! .

Контекстные переменные NEW и OLD

Триггеры могут использовать два полных набора контекстных переменных, представляющих «старое» и «новое» значение каждого столбца таблицы, OLD .имя-столбца ссылается на текущее или предыдущее значение именованного столбца в изменяемой или удаляемой строке. Это не имеет смысла для добавления данных, NEW.имя-столбца ссылается на значение, передаваемое запросом на изменение или добавление. Не имеет смысла для удаления. Если операция обновления не изменяет некоторые столбцы, то для таких столбцов переменная NEW будет иметь то же самое значение, что и переменная OLD. Контекстные переменные часто используются для сравнения значений столбцов до и после изменения.

Контекстные переменные могут применяться везде, где могут быть использованы обычные переменные. Значение NEW для столбца строки может быть изменено только до соответствующего действия. Значения OLD являются значениями только для чтения. Подробности и примеры использования см. в главе 31.

! ! !

СОВЕТ. Поскольку Firebird создает триггеры для реализации ограничений CHECK, контекстные переменные OLD и NEW могут использоваться непосредственно в ограничениях CHECK, например:

ALTER TABLE EMPLOYEE

ADD CONSTRAINT EMPLOYEE_SALARY_RAISE_CK

CHECK ((OLD.SALARY IS NULL) OR (NEW.SALARY > OLD.SALARY));

. ! .

Операторы SELECT … INTO

Используйте оператор SELECT С предложением INTO для поиска значений столбцов в таблицах и сохранения их в локальных переменных или выходных аргументах.

Одиночный оператор SELECT

Обычный оператор SELECT В PSQL должен возвращать не более одной строки из базы данных- стандартный одиночный (singleton) оператор SELECT. ЕСЛИ оператор возвращает более одной строки, то будет выдано исключение. Предложение ORDER BY недопустимо в одиночном SELECT кроме случая, когда используется оператор SELECT FIRST 1. (Информацию об использовании квалификатора FIRST см. В znaee 21.)

Обычные правила применяются к входному списку, предложению WHERE и предложению GROUP BY, если оно используется. Предложение INTO требуется и должно быть последним предложением в операторе.

Пример одиночного оператора SELECT В параметризованном запросе DSQL в приложении:

SELECT SUM(BUDGET), AVG(BUDGET)

FROM DEPARTMENT

WHERE HEAD_DEPT = :head_dept;

Для использования этого оператора в процедуре объявите локальные переменные или выходные аргументы и добавьте предложение INTO в конец:

. . .

DECLARE VARIABLE TOT_BUDGET NUMERIC(18,2);

DECLARE VARIABLE AVG_BUDGET NUMERIC(18,2);

. . .

SELECT SUM(BUDGET), AVG(BUDGET)

FROM DEPARTMENT

WHERE HEAD_DEPT = :head_dept

INTO :tot_budget, :avg_budget;

Операторы SELECT для множества строк

Любой модуль PSQL может оперировать с множеством входных строк, полученных из оператора SELECT, когда он содержит структуру цикла, который может «перемещаться» по набору и выполнять одинаковую обработку каждой строки. PSQL не может обрабатывать многострочные наборы другим способом, и при отсутствии контекста цикла многострочная выборка данных вызовет исключение («Multiple rows in singleton select» — «Множество строк в одиночном операторе SELECT»).

Циклы FOR SELECT…

Основным методом реализации структуры цикла для обработки многострочных входных наборов является структура FOR … SELECT … INTO … DO. Его упрощенный синтаксис:

FOR SELECT <список-спецификации-набора>

FROM имя-таблицы

[JOIN..]

[WHERE..]

[GROUP BY. . ]

[ORDER BY. . ]

INTO <список-переменных> DO

BEGIN

< блок-обработки>

. . .

[SUSPEND] ;

END

В качестве примера рассмотрим следующую процедуру, получающую набор от оператора SELECT, который передает строки, по одной за один раз, в буфер курсора процедуры. Она проходит по набору, устанавливая значения для набора переменных в соответствии со спецификацией таблицы. В конце цикла процедура добавляет запись во внешнюю таблицу.

CREATE PROCEDURE PROJECT_MEMBERS

DECLARE VARIABLE PROJ_NAME CHAR(23);

DECLARE VARIABLE EMP_NO CHAR(6);

DECLARE VARIABLE LAST_NAME CHAR(23);

DECLARE VARIABLE FIRST_NAME CHAR (18);

DECLARE VARIABLE HIRE_DATE CHAR(12);

DECLARE VARIABLE JOB_TITLE CHAR(27) ;

DECLARE VARIABLE CRLF CHAR (2);

BEGIN

CRLF = ASCII_CHAR(13) || ASCII_CHAR(10);

/* Windows EOL — признак конца строки */

FOR SELECT DISTINCT

P.PROJ_NAME,

E.EMP_NO,

E.LAST_NAME,

E.FIRST_NAME,

E.HIRE_DATE,

J.JOB_TITLE

FROM EMPLOYEE E

JOIN JOB J ON E.JOB_CODE = J.JOB_CODE

JOIN EMPLOYEE_PROJECT EP ON E.EMP_NO = EP.EMP_NO

JOIN PROJECT P ON P.PROJ_ID = EP.PROJ_ID

ORDER BY P.PROJ_NAME, E.LAST_NAME, E.FIRST_NAME

INTO /* переменные для столбцов */

:PROJ_NAME, :EMP_NO, :LAST_NAME, :FIRST_NAME,

:HIRE_DATE, :JOB_TITLE

BEGIN /* начинает цикл присваивания значений переменным */

PROJ_NAME = «»И CAST (PROJ_NAME AS CHAR(20) ) || «» ||’ , ‘ ;

EMP_NO = CAST (EMP_NO AS CHAR (5) ) || ‘ , ‘ ;

LAST_NAME = «»|| CAST (LAST_NAME AS CHAR(20) ) || «» ||’ , ‘ ;

FIRST_NAME = «»|| CAST (FIRST_NAME AS CHAR (15) ) || «» || ‘ , ‘;

HIRE_DATE = CAST(HIRE_DATE AS CHAR(11)) || ‘ , ‘;

JOB_TITLE = «»|| CAST (JOB_TITLE AS CHAR (25) ) || «» ;

INSERT INTO EXT_FILE

VALUES (:PROJ_NAME, :EMP_NO, :LAST_NAME,

:FIRST_NAME,:HIRE_DATE, :JOB_TITLE,

CRLF) ;

END /* завершает цикл DO */

END ^

! ! !

ВНИМАНИЕ! Если выходному параметру не присваивается значение, его значение будет непредсказуемым, что может привести к ошибкам. Процедура должна обеспечить инициализацию всех выходных параметров до начала процесса присваивания значений; это должно гарантировать, что оператор SUSPEND передаст допустимые выходные данные.

. ! .

SUSPEND

Оператор SUSPEND имеет специфическое использование в конструкции FOR … SELECT … INTO … DO. Если SUSPEND включен в цикл DO, то после того, как SELECT прочтет строку в переменные строки, цикл будет ждать, когда эта строка будет выведена в кэш строк сервера перед получением следующей строки из курсора SELECT. Такая операция позволяет создавать в Firebird хранимые процедуры выбора.

В следующей главе мы более подробно рассмотрим использование операторов SELECT, которые возвращают множество строк в хранимые процедуры, и технику написания хранимых процедур выбора.

Оператор SUSPEND недопустим в триггерах. В выполняемых хранимых процедурах он имеет тот же эффект, что и оператор EXIT — т. е. он немедленно завершает процедуру, а все операторы, следующие за ним, никогда не будут выполняться.

По контрасту, если процедура выбора имеет выполняемые операторы, следующие за последним оператором SUSPEND В процедуре, то все эти операторы будут выполнены, даже если нет больше строк, возвращаемых вызвавшей программе. Процедуры такого рода завершаются финальным оператором END.

Операторы управления потоком

PSQL содержит множество операторов, которые влияют на поток управления в кодах модулей. Только что рассмотренный оператор SUSPEND передает управление назад вызвавшей процедуре или клиентской программе, ожидая, когда только что обработанная строка будет получена из кэша строк сервера.

EXIT

В процедурах выбора и в выполняемых процедурах EXIT вызывает переход на финальный оператор END В процедуре. Он не имеет смысла в триггерах.

Поведение операторов SUSPEND, EXIT и END описано в табл. 29.2.

Таблица 29.2. Операторы SUSPEND, EXIT и END

Тип модуля	SUSPEND	EXIT	END
Процедура выбора	Выполнение приостанавливается, пока вызвавшее приложение или процедура получает следующий набор выходных переменных	Возвращает значения (если присутствуют) и переходит на финальный END	Возвращает управление приложению и устанавливает SQLCODE В 100
Выполняемая процедура	Переходит на финальный END — не рекомендуется	Переходит на финальный END	Возвращает значения и передает управление приложению
Триггеры	Никогда не используется	Переходит на финальный END	Передает управление следующему триггеру той же фазы (BEFORE или AFTER), что и у текущего, если тот существует. Иначе завершает работу триггеров этой фазы

LEAVE

В Firebird 1.5 появился оператор LEAVE для выхода из блоков. Он заменил оператор BREAK, который был частично реализован в версии 1.0.x. Вот пример его использования в цикле WHILE нашей процедуры IS_PORK_SAFE:

WHILE (SI < 9) DO

BEGIN

SI = SI + 1; /* арифметическое выражение */

IF (SUBSTRING(SMONTH FROM 1 FOR 1) = ‘R’) THEN

BEGIN

RESPONSE = ‘YES’; /* простая константа */

LEAVE;

END

SMONTH = SUBSTRING(SMONTH FROM 2);

/* функциональное выражение */

END

LEAVE приводит к выходу из цикла — в нашем случае останавливается проверка букв слова на символ «R». Если ветвь, содержащая оператор LEAVE, не выполняется, то выполнение продолжается до конца цикла.

EXCEPTION

Оператор EXCEPTION останавливает выполнение и передает управление первому блоку обработки исключений (блоку, начинающемуся с ключевого слова WHEN), который может обработать исключение. Если для этого исключения не найден обработчик, управление передается финальному оператору END и процедура завершается аварийно. Когда происходит такое, один или более кодов исключения передается назад клиенту через вектор состояния ошибок (массив).

Оператор EXCEPTION используется в блоке IF … THEN … ELSE для вызова пользовательских исключений, предварительно определенных как объекты базы данных. Сервер Firebird вызывает свои собственные исключения для SQL и контекста ошибок. Поток управления в этих случаях точно такой же, как и при вызове пользовательских исключений.

Синтаксис и техники вызова и обработки исключений описаны в главе 32.

EXECUTE STATEMENT

Firebird 1.5 вводит расширение PSQL, поддерживающее выполняемые строки. Приложение или процедура могут передать оператор DSQL (DDL или DML) в виде строки входного аргумента (либо процедура может сконструировать эту строку как локальную переменную) для выполнения с использованием EXECUTE STATEMENT.

EXECUTE STATEMENT добавляет гибкости хранимым процедурам и триггерам, но с высоким риском ошибок. Возвращаемые значения жестко проверяются на типы данных, чтобы избежать непредсказуемых исключений преобразования данных. Например, строка ‘1234’ может быть преобразована в целое, a ‘abc’ вызовет ошибку преобразования. Во время компиляции такая строка не может быть проанализирована и проверена.

Синтаксис:

[FOR] EXECUTE STATEMENT <строка>

[INTO :переменная1 [, :переменная2 [, :переменнаяN ] ] DO

<составной-оператор>];

<составной-оператор> = {оператор блок-операторов}

Конструирование выражения или строковой переменной для создания оператора DSQL в строке аргумента должно быть завершено к моменту выполнения EXECUTE STATEMENT. Выполняемый оператор DSQL в строке аргумента не может содержать никаких заменяемых параметров.

В своей простейшей форме EXECUTE STATEMENT выполняет оператор SQL, запрашивающий операцию, которая не возвращает строк данных, а именно:

* INSERT, UPDATE, DELETE;

* EXECUTE PROCEDURE;

* любой оператор DDL за исключением CREATE/DROP DATABASE. Например:

CREATE PROCEDURE EXEC_PROC (PROC_NAME VARCHAR (31))

DECLARE VARIABLE SQL VARCHAR(1024);

DECLARE VARIABLE . . .

BEGIN

. . .

SQL = ‘EXECUTE PROCEDURE ‘ || PROC_NAME;

EXECUTE STATEMENT SQL;

END ^

Процедура вызывает следующее:

EXECUTE PROCEDURE EXEC_PROC ( ‘ PROJECT_MEMBERS ‘ ) ;

Переменные значения в одиночном SELECT

Следующий фрагмент кода показывает, как выполнять строку оператора SELECT, который возвращает одну строку в набор переменных. Как и любой другой оператор SELECT в модуле PSQL, он вызовет исключение, если оператор вернет множество строк. Здесь мы также можем выполнить нечто невозможное в обычном PSQL: выполнить операцию, включающую таблицу или столбец, чье имя неизвестно во время компиляции:

CREATE PROCEDURE SOME_PROC

(TABLE_NAME VARCHAR (31), COL_NAME VARCHAR (31))

DECLARE VARIABLE PARAM DATE;

BEGIN

EXECUTE STATEMENT ‘SELECT MAX ( ‘ || COL_NAME || ‘) FROM ‘ || TABLE_NAME

INTO : PARAM;

. . .

FOR SELECT . . . . FROM . . . .

WHERE END_DATE = : PARAM

INTO … DO

. . .

END ^

Переменные значения в многострочном SELECT

Синтаксис EXECUTE STATEMENT также поддерживает выполнение оператора SELECT внутри цикла FOR для возвращения по одной строки за раз в список переменных. Не существует ограничений на используемый оператор SELECT, однако помните, что во время компиляции синтаксический анализатор не может проверить содержимое строки.

CREATE PROCEDURE DYNAMIC_SAMPLE (

TEXT_COL VARCHAR(31),

TABLE_NAME VARCHAR (31))

RETURNS (LINE VARCHAR(32000))

DECLARE VARIABLE ONE_LINE VARCHAR (100);

DECLARE VARIABLE STOP_ME SMALLINT;

BEGIN

LINE = ‘ ‘ ;

STOP_ME = 1;

FOR EXECUTE STATEMENT

‘SELECT ‘ || TEXTCOL || ‘ FROM ‘ || TABLE_NAME

INTO :ONE_LINE DO

BEGIN

IF (STOP_ME > 320) THEN

EXIT;

IF (ONE_LINE IS NOT NULL) THEN

LINE = LINE || ONE_LINE || ‘ ‘

STOP_ME = STOP_ME + 1;

END

SUSPEND;

END ^

Предостережения

Средство EXECUTE STATEMENT предназначено только для очень осторожного использования и должно применяться с учетом всех факторов. Используемые в нем операции медленны и рискованны. Возьмите за правило применять его только в случае невозможности получить нужные результаты другими средствами или (что маловероятно) когда это действительно улучшает выполнение оператора. Будьте в курсе, что есть риск:

* не существует способа проверить синтаксис оператора в строке аргумента;

* не проверяются зависимости или существование защиты для предотвращения удаления или изменения таблиц или столбцов;

* операции выполняются медленно, потому что встроенный оператор должен подготавливаться на сервере каждый раз перед выполнением;

* если хранимая процедура имеет специальные привилегии к некоторым объектам, то динамический оператор, выдаваемый в строке EXECUTE STATEMENT, не наследует их. Используются те привилегии, которые имеет пользователь, выполняющий процедуру.

POST_EVENT

События Firebird предоставляют механизм сигнализации, который позволяет приложениям прослушивать изменения базы данных, сделанные параллельно выполняющимися приложениями, без необходимости расходовать ресурсы CPU или использовать сетевые ресурсы, опрашивая друг друга.

Синтаксис оператора:

POST_EVENT имя-события;

Это приводит к тому, что событие имя-события «отправляется» в стек, имя-события может быть любой строкой, содержащей до 78 символов и не требующей предварительного определения на сервере. Помещенные в стек события будут отправлены клиентам, «прослушивающим» события с помощью обработчика извещений (event alerter).

Когда транзакция подтверждается, все сообщения, появившиеся в триггерах и хранимых процедурах, отправляются прослушивающим клиентским приложениям. Приложение может отреагировать на сообщение, например, прочитав заново используемый набор данных.

Подробности см. в разд. «События» главы 32.

Разработка модулей

Разработка модулей PSQL является жизненно важной частью деятельности, как разработчика, так и администратора базы данных.

Поскольку запросы администратора Firebird ясны, обычно на практике эти две роли объединяются. В процессе разработки обычно довольно большое количество разработчиков группы разрабатывает, тестирует и изменяет программные модули серверной стороны одновременно. Следовательно, меры, принимаемые для проектирования и стандартизации кода приложений, также важны и для кода PSQL.

Добавление комментариев

Код хранимой процедуры должен быть комментирован для помощи в отладке и в разработке приложений. Комментарии особенно важны в хранимых процедурах, потому что процедуры являются глобальными в базе данных и могут использоваться несколькими разработчиками приложений.

В заголовок и тело модуля PSQL могут быть включены и многострочные, и встроенные комментарии. Синтаксис комментариев подробно обсуждался в главе 14 в разд. «Скрипты схемы».

Чувствительность к регистру и пробелы

Если при создании вами объектов базы данных были использованы квотированные идентификаторы, то все правила чувствительности к регистру, которые применялись к вашим данным динамического SQL, должны также применяться, когда вы ссылаетесь на эти объекты в операторах процедуры.

Весь остальной код не является чувствительным к регистру. Например (предполагая, что не использовались идентификаторы объектов с разделителями), следующие два фрагмента операторов являются эквивалентными:

CREATE PROCEDURE MYPROC…

create procedure myproc…

Компилятор не устанавливает ограничений на количество пробелов или символов перевода строки. Для читаемости вашего кода может быть полезным применение какой-либо формы стандартных соглашений о расположении вашего процедурного кода. Например, вы можете писать все ключевые слова в верхнем регистре, выделять код блоков, размещать объявления переменных на отдельных строках, помещать за- пятые-разделители в начале строки и т.д.

Управление вашим кодом

Учитывая, что языком высокого уровня для программирования на стороне сервера в Firebird является язык SQL и что исходный код представляется серверу в форме «супероператоров» DDL для компиляции в объекты базы данных, не удивительно, что вся поддержка кодов также выполняется с использованием операторов DDL. Эти операторы совместимы с соглашениями по поддержке других объектов в базе данных SQL.

* Переопределению скомпилированных объектов (хранимых процедур и триггеров) служит синтаксис ALTER PROCEDURE | TRIGGER. Для хранимых процедур Firebird также предоставляет синтаксис RECREATE PROCEDURE и (начиная с версии 1.5) CREATE или REPLACE PROCEDURE.

* Операторы DROP PROCEDURE | TRIGGER используются для удаления модулей.

Существует два способа управления процедурами и триггерами: интерактивно вводить операторы с использованием isql или другого инструмента, который может передавать DSQL, или с использованием одного или более выходных файлов, содержащих операторы определения данных, называемых скриптами.

Интерактивный интерфейс кажется более быстрым и простым способом делать эти вещи — но только до первого раза, когда вам понадобится что-нибудь изменить, проверить и пересоздать. Использование скриптов рекомендуется, потому что скрипты не только предоставляют необходимую документацию кодов, но также могут содержать комментарии и могут легко модифицироваться.

Инструменты редактирования

Может быть использован любой текстовый редактор ASCII, который не сохраняет непечатаемые символы за исключением символа перевода строки (ASCII 13), возврата каретки (ASCII 10) и символа табуляции (ASCII 9). Некоторые редакторы имеют средства подсветки ключевых слов SQL: редакторы IDE для Borland Delphi и Kylix, а также некоторые другие инструменты, представленные в приложении 5.

! ! !

СОВЕТ. Утилита командной строки isql может быть использована в качестве редактора при употреблении команды EDIT. Эта команда будет использовать выбранный вами текстовый редактор, если вы установите в вашей системе соответствующие переменные окружения. В POSIX установите переменную окружения VISUAL или EDITOR. В Windows установите EDITOR.

. ! .

Полезной практикой является добавление расширения sql к именам файлов скриптов Firebird. Помимо пользы от идентификации скриптов в вашей файловой системе, расширение sql будет распознаваться как пакетный файл SQL многими инструментами редактирования, которые поддерживают подсветку синтаксиса SQL.

Компиляция хранимых процедур и триггеров

Для компиляции любого файла скрипта вы должны включить в файл, по крайней мере, одну «пустую строку» после последнего оператора или комментария. Чтобы сделать это, нажмите, по меньшей мере, один раз клавишу <Return> (Enter) в вашем текстовом редакторе. Когда вы завершите создание вашей процедуры, сохраните ее в файле с любым понравившимся вам именем.

Для компиляции вашей хранимой процедуры просто выполните ваш скрипт с использованием команды INPUT в isql или в интерфейсе обработки скриптов вашего инструмента управления базой данных.

Ошибки в скриптах

Firebird генерирует ошибки в процессе синтаксического разбора, если присутствует некорректный синтаксис в операторе CREATE PROCEDURE | TRIGGER. Сообщения об ошибках выглядят следующим образом:

Dynamic SQL Error

-SQL error code = -104

-Token unknown — line 4, char 9

-tmp

Нумерация строк начинается со строки, содержащей оператор CREATE, а не С начала файла скрипта. Символы подсчитываются слева направо, а неопределенный элемент указывается либо в виде номера первого символа источника ошибки, либо в виде номера крайнего правого символа источника ошибки. Если есть сомнения, проверяйте всю строку для определения источника синтаксической ошибки.

! ! !

СОВЕТ. Если вы используете версию isql, более позднюю, чем Firebird 1.0, вы заметите улучшение ее возможностей в описании ошибок в скриптах и указании их расположения. Хотя Firebird не содержит средств отладки хранимых процедур, некоторые инструменты сторонних разработчиков имеют такие возможности.

. ! .

Зависимости объектов

Сервер Firebird педантичен при поддержке информации о взаимозависимостях между управляемыми им объектами. Необходимы специальные соглашения при выполнении изменений хранимых процедур, находящихся в текущий момент в использовании другими пользователями. Процедура находится «в использовании» (procedure is in use), когда она в настоящий момент выполняется, или если она была внутренне скомпилирована в кэш метаданных по запросу пользователя. Более того, сервер будет откладывать или запрещать компиляцию операторов ALTER или DROP, если скомпилированная версия будет найдена в кэше метаданных.

Изменения процедур не будут видны клиентским приложениям, пока они не отсоединятся от базы данных и вновь не присоединятся к ней.

! ! !

ПРИМЕЧАНИЕ. Триггеры и хранимые процедуры, вызывающие процедуры, которые были изменены или заново созданы, не имеют доступа к новой версии, пока база данных не окажется в состоянии, когда все клиенты будут отключены.

. ! .

Идеальный вариант — выдача операторов CREATE, RECREATE и ALTER для модулей PSQL в то время, когда не выполняется ни одно клиентское приложение.

Изменение и удаление модулей

Когда вы изменяете процедуру или триггер, новое определение процедуры заменяет старую версию. Для изменения определения процедуры или триггера выполните следующие шаги:

1. Скопируйте файл исходного определения данных, содержащий оператор создания процедуры. В другом варианте — используйте isql -extract для выделения исходного текста процедуры или триггера из базы данных в текстовый файл.

2. Отредактируйте файл, заменив CREATE на RECREATE или ALTER и изменив определение желаемым образом.

3. Выполните измененный скрипт при «чистых» условиях, как было описано ранее. Для удаления модуля выполните:

DROP {PROCEDURE | TRIGGER} имя-модуля;

Привилегии

Только пользователь SYSDBA или владелец процедуры/триггера может изменять или удалять его.

Ошибка «Объект находится в использовании»

Ошибка «Object is in use» (Объект находится в использовании) расстраивает разработчика более чем какая-либо другая. Вы соединились с базой данных как пользователь SYSDBA или владелец базы данных. У вас исключительный доступ, что желательно при изменении метаданных, и вдруг появляется какой-то фантомный пользователь, использующий объект, метаданные которого вы собираетесь изменить или удалить.

Источником этой загадки может быть одна или более следующих ситуаций.

* При останове базы данных (shut down), подготовке к получению исключительного доступа вы (или другой человек) уже были соединены как пользователь SYSDBA, владелец или (в Linux/UNIX) как пользователь с подходящими привилегиями операционной системы. При проверке условий останова базы данных Firebird игнорирует таких пользователей и все их текущие транзакции или те, которые запускаются после начала останова. Любая неподтвержденная транзакция (какой бы она ни была — даже SELECT), которая использует этот объект или любой объект, зависящий от этого объекта, или объект, от которого зависит наш объект, будет вызывать эту ошибку.

* «Заинтересованная транзакция», которая остается в базе данных в результате ненормального завершения работы какого-либо пользователя и которая использует зависимости, связанные с нашим объектом, вызовет такую ошибку.

* Вы или другой пользователь с подходящими привилегиями ранее пытались переопределить или удалить этот объект или другой зависимый объект, и операция была отвергнута по той причине, что объект находился в использовании.

! ! !

ВНИМАНИЕ! Такая ситуация может провоцировать цепочку несогласованностей в вашей базе данных. Например, если gbak выполнялся в то время, когда база данных имела объекты в таком состоянии, то восстановление резервной копии может оказаться невозможным.

Всякий раз, когда вы видите такую ошибку и верите, что вы насколько возможно уменьшили вероятность ее появления, рассматривайте ее как сигнал, что ваша база данных нуждается в проверке до того, как вы продолжите любые дальнейшие изменения метаданных (см. главу 39).

. ! .

Для просмотра в isql списка процедур или триггеров и их зависимостей используйте команду SHOW PROCEDURES или SHOW TRIGGERS соответственно.

Удаление исходных текстов модулей

Разработчики часто хотят «спрятать» исходные коды их модулей PSQL при распространении баз данных. Вы можете удалить хранимые исходные тексты без воздействия на возможности модуля. Только убедитесь, что у вас есть последние версии скриптов, прежде чем это делать!

Исходные тексты всех модулей хранятся в системной таблице RDB$PROCEDURES и RDB $ TRIGGERS.

Удаление исходного текста процедуры:

UPDATE RDB$PROCEDURES

SET RDB$PROCEDURE_SOURCE = NULL

WHERE RDB$PROCEDURE NAME = ‘MYPROC’;

Удаление исходного текста триггера:

UPDATE RDB$TRIGGERS

SET RDB$TRIGGER_SOURCE = NULL

WHERE RDB$TRIGGER_NAME = ‘MYTRIGGER’;

! ! !

ВНИМАНИЕ! Имейте в виду, что такое удаление исходных кодов не остановит тех, кто серьезно собирается украсть ваш исходный код. Исполняемый код хранится в двоичном формате, который очень просто может быть преобразован обратно в PSQL. Следовательно, решите, будет ли выгода от утаивания PSQL больше затрат, которые вы и другие, кто поддерживает систему, понесут от потери возможности просмотра и выделения исходного текста.

. ! .

Пора дальше

Далее мы подробно рассмотрим возможности языка PSQL и техники, которые вы можете использовать для разработки хранимых процедур и структуризации вашего кода. Специальная тема в конце главы описывает RDB$DB_KEY, внутренний уникальный атрибут каждой строки в каждом наборе, который может быть полезен при оптимизации выполнения некоторых операций PSQL.

ГЛАВА 30. Хранимые процедуры.

Процедура является самостоятельной программой, написанной на языке PSQL Firebird, скомпилированной интерпретатором во внутренний двоичный язык Firebird и сохраненной как исполняемый код в метаданных базы данных. Однажды скомпилированная, хранимая процедура может быть вызвана непосредственно из приложения или другого модуля PSQL с использованием оператора EXECUTE PROCEDURE или SELECT в соответствии с заданным стилем процедуры.

Хранимые процедуры могут принимать входные параметры от клиентских приложений в качестве аргументов вызываемого запроса. Они могут возвращать приложениям набор значений в качестве выходных параметров.

Язык процедур и триггеров Firebird включает SQL-операторы манипулирования данными и некоторые мощные расширения, в том числе конструкции IF … THEN … ELSE, WHILE … DO, FOR SELECT … DO, определенные в системе исключения, обработку ошибок и события.

Хранимые процедуры могут быть вызваны из приложений с использованием динамических операторов SQL. Они также могут быть вызваны интерактивно из isql и из многих других инструментов работы с базами данных, рекомендованных для использования с Firebird. Исполняемые модули, включая вложенные процедуры, могут быть использованы в скриптах с тем ограничением, что все входные параметры являются константами и не существует выходных наборов. В скриптах не существует возможности передавать переменные параметры.

Выполняемые хранимые процедуры

Процедуры, которые вызываются с помощью оператора EXECUTE PROCEDURE, могут возвращать одну строку из одного или более выходных значений. Они часто используются для выполнения операций добавления, изменения или удаления или для запуска набора операций, таких как пакетный импорт или экспорт данных.

Хранимые процедуры выбора

Хранимые процедуры выбора названы так, потому что они написаны с использованием некоторых специальных расширений языка для создания многострочных выходных наборов, возвращающихся вызвавшей программе, которая использовала запрос SELECT — «виртуальные таблицы».

Сервер не различает процедуры выбора и выполняемые процедуры. Если требуется, он попытается выбрать набор записей из выполняемой процедуры или выполнить что-нибудь в процедуре выбора- и, естественно, будет вызывать исключение, если возникнут ошибки в запросе! Это ваша задача убедиться, что ваш код на сервере делает именно то, что вы от него ожидали, и что код приложения посылает соответствующие запросы.

Создание хранимых процедур

В вашем скрипте или в isql начните с установки символа терминатора, который будет использован для отметки конца синтаксиса CREATE PROCEDURE. Следующий пример устанавливает символ терминатора в &:

SET TERM &;

Синтаксис оператора:

CREATE PROCEDURE имя-процедуры

[(аргумент тип-данных [, аргумент тип-данных […]])]

[RETURNS (аргумент тип-данных [, аргумент тип-данных […]])

< тело -процедуры>

<тело-процедуры> =

[DECLARE [VARIABLE] переменная тип-данных;

[…]]]

BEGIN

<составной-оператор>;

END <терминатор>

Элементы заголовка

Объявляйте в заголовке:

* имя процедуры, которое обязательно и должно быть уникальным в базе данных, например:

CREATE PROCEDURE MyProc

* любые необязательные входные параметры (аргументы), требуемые в процедуре, с их типами данных. Список заключается в скобки, параметры отделяются друг от друга запятыми, например:

CREATE PROCEDURE MyProc (invarl integer, invar2 date)

* имя каждого аргумента должно быть уникальным в процедуре. Тип данных может быть любым стандартным типом данных SQL за исключением массива типов

данных. Не требуется соответствия имен входных аргументов именам параметров в вызывающей программе;

* любые необязательные выходные параметры (аргументы), требуемые в процедуре, с их типами данных. Список следует за ключевым словом RETURNS. список заключается в скобки, параметры отделяются друг от друга запятыми, например:

CREATE PROCEDURE MyProc

(invar1 INTEGER, invar2 DATE)

RETURNS (outvar1 INTEGER, outvar2 VARCHAR(20), outvar3 DOUBLE PRECISION)

* имя каждого аргумента должно быть уникальным в процедуре. Тип данных может быть любым стандартным типом данных SQL за исключением массива типов данных;

* ключевое слово AS, которое обязательно:

CREATE PROCEDURE MyProc

(invar1INTEGER, invar2 DATE)

RETURNS(outvar1 INTEGER, outvar2 VARCFAR(20), outvar3 DOUBLE

PRECISION)

Элементы тела

Синтаксис:

< тело-процедуры> = [<список-объявлений-переменных>] <составной-оператор>

Локальные переменные

Если вам нужно объявить локальные переменные, то это следует сделать далее. Каждое объявление завершается точкой с запятой. В версии 1.5 переменные при их объявлении могут инициализироваться. Синтаксис:

<список-объявлений-переменных> =

DECLARE [VARIABLE] переменная тип-данных [{‘=’ | DEFAULT} значение];

[DECLARE [VARIABLE] переменная тип-данных; . . .]

Пример:

CREATE PROCEDURE MyProc (

invar1 INTEGER,

invar2 DATE)

RETURNS (

outvar1 INTEGER,

outvar2 VARCHAR(20),

outvar3 DOUBLE PRECISION)

DECLARE VARIABLE localvar integer DEFAULT 0;

DECLARE VARIABLE anothervar DOUBLE PRECISION = 0.00;

! ! !

ПРИМЕЧАНИЕ. Ключевое слово VARIABLE необязательно в версии 1.5 и выше.

. ! .

Главный блок кода

Следом идет главный блок кода, обозначенный в описании синтаксиса как <составной-оператор>. Он начинается ключевым словом BEGIN и заканчивается ключевым словом END.

Синтаксис:

<составной-оператор> =

BEGIN

<составной-оператор>

[<составной-оператор> …]

END <терминатор>

Все структуры <составной-оператор> состоят из одного оператора и/или других структур <составной-оператор>, которые могут включать другие вложенные структуры, например:

CREATE PROCEDURE MyProc (

invar1 INTEGER,

invar2 DATE)

RETURNS (

outvar1 INTEGER,

outvar2 VARCHAR(20),

outvar3 DOUBLE PRECISION)

DECLARE VARIABLE localvar integer DEFAULT 0;

DECLARE VARIABLE anothervar DOUBLE PRECISION = 0.00;

BEGIN

< составной-оператор>

END &

Элементами в <составной-оператор> могут быть: любой одиночный оператор, блок операторов и вложенные блоки операторов, заключенные в операторные скобки BEGIN и END. Блоки могут включать:

* операторы присваивания, устанавливающие значения локальным переменным и входным/выходным параметрам;

* операторы SELECT для помещения значений столбцов в переменные. Операторы SELECT должны иметь предложение INTO в качестве последнего предложения и объявления соответствующих локальных переменных или выходных аргументов для каждого выбранного столбца;

* структуры циклов, такие как FOR SELECT … DO и WHILE … DO для выполнения условных или циклических задач;

* структуры ветвления с использованием IF … THEN … [ELSE];

* операторы EXECUTE PROCEDURE для вызова других процедур с необязательным предложением RETURNING_VALUES для получения значений переменных. Допустима рекурсия;

* операторы SUSPEND и EXIT, возвращающие управление и, возможно, значения вызвавшему приложению или модулю PSQL;

* комментарии для аннотирования кода процедуры;

* операторы EXCEPTION для возврата приложениям пользовательских сообщений об ошибках или для задания условий для обработчиков исключений;

* операторы WHEN для обработки особых или общих условий ошибок.

* операторы POST_EVENT для добавления в стек сообщений о событиях. Пример:

BEGIN

FOR SELECT COL1, COL2, COL3, C0L4

FROM TABLEA INTO :COL1, :COL2, :COL3 DO

BEGIN

<операторы>

END

<операторы>

END &

SET TERM ; &

COMMIT;

Обратите внимание на завершение всего объявления процедуры символом терминатора, ранее определенного оператором SET TERM. После текста тела процедуры символ терминатора устанавливается в значение по умолчанию точка с запятой. Так поступать следует не всегда. В скриптах DDL, где вы объявляете несколько модулей PSQL, вы можете сохранять альтернативный оператор текущим. Некоторые люди на практике используют альтернативный терминатор во всех своих скриптах, таким образом резервируя точку с запятой только для завершения оператора PSQL. Здесь дело в личных предпочтениях.

Выполняемые процедуры

Когда вы работаете с языком хранимых процедур Firebird и структурами программных модулей, необходимо различать процедуры, которые выполняются с целью изменения данных, и процедуры, которые собираются возвращать виртуальную таблицу вызвавшему приложению, как и оператор SELECT. Первый вид больше всего знаком тем, кто использовал в работе другие системы управления базами данных, — это выполняемые процедуры.

Сложная обработка

Одним из наиболее очевидных и общих способов использования выполняемых процедур является выполнение сложных вычислений над входными данными и выполнение изменений одной или более таблиц. Сложные бизнес-правила и подпрограммы размещаются на сервере. Любое клиентское приложение с соответствующими разрешениями может вызывать эти подпрограммы и получать результаты, независимо от включающего языка программирования. Не говоря об экономии многих часов на программирование и тестирование, выполнение на стороне сервера снижает риск нарушения целостности, который возникает за счет повторения одних и тех же сложных операций в различных клиентских языковых средах.

Поддержка «живых» клиентских наборов

Многие клиентские интерфейсы реализуют классы наборов данных или наборов записей, которые получают выходные наборы от операторов SELECT. Такие клиентские классы обычно предоставляют методы DML, которые выбирают одну строку из буфера, хранящего выход курсора серверной стороны. Строка выбирается пользователем, и объект класса использует уникальный ключ строки для моделирования позиционированного изменения или удаления из таблицы базы данных. Для добавления объект «открывает пустую строку», вводит список столбцов того же типа, что и в буфере, и принимает ключ и другие значения в качестве входных данных для столбцов.

Одиночный оператор UPDATE, DELETE или INSERT в SQL может оперировать только с одной таблицей. Когда набор данных (набор записей) выбирается из обычной таблицы и содержит уникальный ключ таблицы, он может рассматриваться как «живой», потому что его методы могут передавать операторы UPDATE, DELETE или INSERT. Обычным термином для такого типа набора является естественно изменяемый. Набор, являющийся соединением нескольких таблиц, не будет естественно изменяемым. Выполняемые хранимые процедуры могут быть созданы с входными аргументами, которые принимают ключи и значения для множества таблиц и выполняют требуемые операции над каждой таблицей. Такая техника позволяет клиентским приложениям трактовать соединенные наборы, как если бы они были «живыми».

Операции в выполняемых процедурах

Практически любое манипулирование данными в SQL доступно в выполняемой хранимой процедуре. Все действия выполняются в контексте транзакции вызвавшей процедуру программы и подтверждаются, когда подтверждается эта транзакция. Для строк, измененных операциями в процедуре, создаются версии точно таким же способом, как если бы они были отправлены запросами DML с клиента.

Процедуры могут вызывать другие процедуры, передавая переменные в качестве входных аргументов и получая возвращаемые значения в переменные, используя предложение RETURNING_VALUES. Они могут добавлять одну или множество строк, изменять отдельные строки, формировать курсоры для серии строк для позиционирования изменений и удалений и выполнять поисковые изменения и удаления.

Рис. 30.1. Операции выполняемой процедуры

Когда процедура начинает выполняться, значения, переданные ей в качестве входных аргументов, становятся локальными переменными. Выходные аргументы являются переменными чтения/записи и могут изменять значения (но не тип данных) в процессе работы много тысяч раз. На рис. 30.1 иллюстрируется типичная деятельность выполняемой процедуры.

Многотабличные процедуры

Выполняемая процедура DELETE_EMPLOYEE является версией процедуры, которую вы можете найти в базе данных EMPLOYEE в вашем каталоге Firebird /examples. Она реализует некоторые бизнес-правила для служащих, покидающих компанию.

Объявление исключения

Поскольку мы собираемся использовать исключение в этой процедуре, его нужно создать до создания процедуры:

CREATE EXCEPTION REASSIGN_SALES

‘Reassign the sales records before deleting this employee.’ ^

COMMIT ^

(Переназначьте записи продаж перед удалением этого служащего)

Процедура

Теперь сама процедура. Входной аргумент EMP_NUM соответствует первичному ключу таблицы EMPLOYEE- EMP_NO. Он позволяет процедуре выбирать и работать с одной записью служащего, а внешние ключи из других таблиц ссылаются через него на эту запись.

CREATE PROCEDURE DELETE_EMPLOYEE (

EMP_NUM INTEGER )

DECLARE VARIABLE any_sales INTEGER DEFAULT 0;

BEGIN

Мы собираемся выяснить, имеет ли этот служащий какие-либо незавершенные заказы на продажи. Если да, мы выдаем исключение. В главе 32 мы соберем такую же процедуру и реализуем некоторую дополнительную обработку для перехвата исключения и обработки этого условия прямо внутри процедуры. Сейчас же мы позволим процедуре завершиться и использовать это сообщение об исключении для информирования вызвавшей программы об этой ситуации.

Конструкция SELECT … INTO

Конструкция SELECT … INTO обычна для PSQL. Когда из таблицы запрашиваются значения, предложение INTO позволяет сохранить их в переменных — в локальных переменных или в выходных аргументах. В этой процедуре нет выходных параметров. Мы используем переменную ANY SALES, которую мы объявили и инициализировали в начале тела процедуры для хранения счетчика записей продаж. Обратите внимание на префикс двоеточия (:) у переменной ANY_SALES. Мы рассмотрим это, когда процедура будет готова.

SELECT count(po_number) FROM sales

WHERE sales_rep = :emp_num

INTO :any_sales;

IF (any_sales > 0) THEN

EXCEPTION reassign_sales;

В случае если такие записи заказов будут найдены, процедура аккуратно завершается на операторе EXCEPTION, который при отсутствии обработчика исключений передает выполнение прямо на самый последний оператор END процедуры. В этих условиях процедура завершается, а сообщение об исключении передается вызвавшей программе^[115].

Если нет исключения, выполнение продолжается. Затем процедура должна выполнить небольшую работу по изменению некоторых позиций вакантной должности (NULL), если она сохраняется для нашего служащего, удалить служащего из проектов и удалить его (или ее) историю продаж. Под конец удаляется сама запись служащего.

UPDATE department

SET mngr_no = NULL

WHERE mngr_no = :emp_num;

UPDATE project

SET team_leader = NULL

WHERE team_leader = :emp_num;

DELETE FROM employee_project

WHERE emp_no = :emp_num;

DELETE FROM salary_history

WHERE errp_no = :emp_num;

DELETE FROM employee

WHERE errp_no = :emp_num;

Работа сделана, служащий ушел. Необязательный оператор EXIT может быть включен в текст с целью документирования. Он может быть весьма полезным, если вы просматриваете скрипты, содержащие множество определений процедур, а эти процедуры имеют много вложенных блоков BEGIN … END:

EXIT;

END ^ COMMIT ^

Префикс двоеточия (:) для переменных

В этой процедуре мы заметили два различных способа использования префикса двоеточия в переменных.

* Раньше применялось обращение к локальной переменной -.ANY SALES, когда она использовалась в предложении INTO для помещения элемента данных, возвращаемого оператором SELECT.

* В более поздних операторах она использовалась с другими целями. Синтаксис PSQL требует наличия префикса двоеточия для любой переменной или аргумента, когда они используются в операторе DSQL.

Эти два способа использования префикса двоеточия являются постоянными в PSQL. Если вы забыли, где их нужно применять, или используете их там, где PSQL не требует, то ваша процедура не будет компилироваться, а синтаксический анализатор вызовет исключение. Хуже, если переменная с тем же именем, что и столбец таблицы, используется в операторе SQL без двоеточия. Сервер считает, что это ссылка на столбец, выполняет оператор и вызывает исключение. Нечего и говорить, что результат такой операции будет непредсказуемым.

Использование (вызов) выполняемых процедур

Выполняемая процедура вызывается оператором EXECUTE PROCEDURE. Она может возвращать не более одной выходной строки. Для выполнения хранимой процедуры в isql используйте следующий синтаксис:

EXECUTE PROCEDURE ИМЯ [(] [ аргумент [, аргумент . . . ] ] [) ] ;

Имя процедуры должно быть задано.

Значения входных аргументов

Правила, касающиеся аргументов, следующие:

* значения должны быть заданы для всех входных аргументов;

* если есть несколько входных аргументов, они должны отделяться друг от друга запятыми;

* каждый аргумент является константой, выражением, преобразуемым в константу или заменяемым параметром;

* переменные могут передаваться как входные аргументы только внутри модуля PSQL;

* заменяемые параметры могут передаваться только внешним операторам DSQL;

* константы и выражения, которые преобразуются в константы, являются допустимыми для любого вызова;

* выражения, которые оперируют с переменными или заменяемыми параметрами, недопустимы;

* скобки, заключающие список аргументов, необязательны.

Поскольку наша процедура DELETE_EMPLOYEE не возвращает аргументов, синтаксис ее вызова из клиентского приложения и из другой процедуры одинаков:

EXECUTE PROCEDURE DELETE_EMPLOYEE (29) ;

При этом, когда процедура вызывается из другой процедуры, входные аргументы могут быть (и обычно бывают) представлены переменными. Поскольку EXECUTE PROCEDURE является оператором DSQL, синтаксис требует, чтобы имя переменной имело префикс точку с запятой:

EXECUTE PROCEDURE DELETE_EMPLOYEE (:EMP_NUMBER);

Другая процедура ADD_EMP_PROJ получает два входных аргумента, ключ служащего и проекта соответственно. Пример вызова может быть таким:

EXECUTE PROCEDURE ADD_EMP_PROJ (32, ‘MKTPR’);

Заменяемые параметры используются для входных аргументов при вызове этой процедуры из клиентского приложения:

EXECUTE PROCEDURE ADD_EMP_PROJ (?, ?) ;

Выводы и выходы

Если выходному параметру не было определено значение, то его значение непредсказуемо, и это может привести к ошибке, иногда достаточной для нарушения целостности данных. В процедуре следует обеспечить инициализацию всех выходных параметров значениями по умолчанию, до того как нужные значения получатся в процессе обработки и будут выданы при выполнении операторов SUSPEND и EXIT.

EXIT и SUSPEND

В процедурах выбора и в выполняемых процедурах оператор EXIT приводит к немедленному переходу к финальному оператору END без выполнения других операторов.

Что произойдет, если процедура достигнет финального оператора END, зависит от ее типа.

* В процедуре SELECT код SQLCODE будет установлен в 100 для указания того, что больше нет найденных строк, а управление перейдет вызвавшей программе.

* В выполняемой процедуре управление перейдет к вызвавшей программе с передачей ей выходных значений, если они присутствуют. Вызовы из триггеров или процедур получают выходные данные через переменные, как задано в RETURNING_VALUES. Приложение получает их в структуре записи.

В выполняемых процедурах SUSPEND имеет точно такой эффект, что и END.

Рекурсивные процедуры

Если процедура вызывает саму себя, она является рекурсивной. Рекурсивные процедуры полезны для задач, включающих повторяющиеся шаги.

Каждое обращение к процедуре называется экземпляром (instance), поскольку каждое обращение к процедуре является отдельной сущностью, которая выполняется так же, как если бы она была вызвана из приложения; она резервирует память и стек с учетом требований выполнения ее задач.

Хранимые процедуры могут иметь глубину вложений не более 1000. Такое ограничение помогает предотвратить бесконечные циклы, которые могут появиться, если в процедуре не задано условие завершения цикла. Однако ограничения памяти и размера стека могут сделать количество вложенных уровней меньше 1000.

Процедура DEPT_BUDGET в примере базы данных EMPLOYEE иллюстрирует работу рекурсивной процедуры. Она принимает в качестве входа код DNO, эквивалентный коду DEPT_NO — ключу таблицы DEPARTMENT. Таблица DEPARTMENT имеет многоуровневую древовидную структуру: каждый отдел, не являющийся головным отделом, имеет внешний ключ HEAD_DEPT, ссылающийся на DEPT_NO своего непосредственного «родителя».

Процедура обращается к таблице DEPARTMENT по этому полученному ключу. Она сохраняет значение BUDGET этой строки в выходной переменной тот. Она также выполняет подсчет количества отделов, непосредственно предшествующих данному отделу в структуре отделов. Если нет подотделов, оператор EXIT осуществляет переход сразу на финальный оператор END ^. Текущее значение тот становится выходом процедуры, и процедура завершается.

SET TERM ^;

CREATE PROCEDURE DEPT_BUDGET (

DNO CHAR(3) )

RETURNS (

TOT DECIMAL(12,2) )

DECLARE VARIABLE sumb DECIMAL(12, 2);

DECLARE VARIABLE rdno CHAR(3);

DECLARE VARIABLE cnt INTEGER;

BEGIN

tot = 0;

SELECT budget FROM department WHERE dept_no = :dno INTO :tot;

SELECT count(budget) FROM department WHERE head_dept = :dno INTO :cnt;

IF (cnt = 0) THEN

EXIT;

Если существуют подотделы, то выполнение продолжается. Входной код DNO используется в предложении WHERE курсора FOR … SELECT (см. разд. «Курсоры в PSQL») для выделения по очереди каждой строки из таблицы DEPARTMENT, которая содержит в коде HEAD_DEPT то же значение, что и в DNO, и помещения значение из DEPT_NO этой строки в локальную переменную RDNO:

FOR SELECT dept_no FROM department

WHERE head_dept = :dno

INTO :rdno DO

BEGIN

Эта локальная переменная теперь становится входным кодом для рекурсивного вызова процедуры. При каждой рекурсии выходное значение тот увеличивается на значение возвращаемого бюджета, пока не будут обработаны все соответствующие строки:

EXECUTE PROCEDURE dept_budget :rdno RETURNING_VALUES :sumb;

tot = tot + sumb;

END

Под конец возвращаемое значение, аккумулированное в рекурсиях, передается вызвавшей программе, и процедура завершается:

EXIT; /* оператор EXIT необязателен */

END^

COMMIT^

Вызов процедуры

На этот раз наша процедура имеет входные параметры. Наш простой вызов в DSQL может выглядеть следующим образом:

EXECUTE PROCEDURE DEPT BUDGET (‘600’);

Или же мы можем использовать заменяемый параметр:

EXECUTE PROCEDURE DEPT_BUDGET (?);

Курсоры в PSQL

Курсоры состоят из трех основных элементов:

* набора строк, определенных выражением SELECT;

* указателя, который перемещается через набор от первой строки к последней, изолируя строку для некоторого вида деятельности;

* набора переменных- определенных как локальные переменные, выходные аргументы или и те, и другие, — для получения значения столбцов, возвращаемых каждой строкой при ссылке на них указателя.

Проход указателя через набор может рассматриваться как операция «цикла». Операции, выполняющиеся в процессе этого «цикла», когда указатель ссылается на строку, могут быть простыми или сложными.

PSQL имеет две реализации курсора, одна хорошо известная, а другая не была ранее документирована.

* Хорошо известная реализация представлена конструкцией FOR … SELECT, которая полностью реализует синтаксис цикла и широко используется в процедурах выбора. Она подробно обсуждается в следующем разделе. При этом также допустимо выполнение цикла курсора FOR … SELECT и внутри выполняемых процедур, как мы видели в предыдущем примере.

* Менее известной реализацией является ранняя реализация, иногда называемая изменяемым или именованным курсором, которая была наследована от ESQL и долгое время была осуждаема. Она представляет объект курсор и позволяет выполнять изменения и удаления. Ее синтаксис будет более понятен тем, кто использовал курсоры в языках процедур в других СУБД. Сейчас мы его вкратце рассмотрим.

! ! !

ПРИМЕЧАНИЕ. Синтаксис и механизм именованного курсора были заново реализованы в процессе разработки Firebird 2. Это краткое описание является лебединой песней старых курсоров, поскольку новый синтаксис вряд ли будет совместимым со старым.

. ! .

«Старый» изменяемый курсор

Его синтаксис выглядит следующим образом:

. . .

FOR SELECT <список-столбцов>

FROM <имя-таблицы>

FOR UPDATE

INTO <переменные>

AS CURSOR <имя-курсора>

/* либо UPDATE … */

BEGIN

UPDATE <имя-таблицы>

SET … WHERE CURRENT OF <имя-курсора>;

. . .

END

/* или DELETE */

BEGIN

DELETE FROM <имя-таблицы>

WHERE CURRENT OF <имя-курсора>

END

. . .

Используйте его сейчас, но ждите изменений в более поздних версиях Firebird. Это очень быстрый способ добавить множество операций в хранимую процедуру, поскольку здесь используется RDB$DB_KEY для локализации записей. RDB$DB_KEY (или просто DBKEY) является внутренней возможностью, которая может быть использована во множестве ситуаций. См. разд. «Темы оптимизации: использование внутреннего RDB$DBKEY».

! ! !

СОВЕТ. Просмотрите заметки по релизу для нового синтаксиса курсора PSQL. На момент написания данной книги описание отсутствовало.

. ! .

Более поздняя реализация курсоров, обсуждаемая далее, является более гибкой.

Хранимые процедуры выбора

Хранимые процедуры выбора называются так, потому что они разрабатываются для выполнения с помощью оператора SELECT. для читателей, привыкших к техникам программирования на сервере, доступным в других СУБД, концепция хранимой процедуры, которая передает строки непосредственно вызвавшему приложению или процедуре без создания промежуточной «временной» таблицы, будет менее понятной, чем выполняемые процедуры.

Использование процедур выбора

Процедуры выбора могут быть использованы для виртуального задания любого набора, однако они особенно полезны, когда нужен набор, который не может быть извлечен или его извлечение выполняется медленно или слишком сложно в одном операторе DSQL.

Эзотерические наборы

Техника хранимых процедур выбора предоставляет колоссальную гибкость для извлечения наборов; эта техника превосходит логику, доступную в спецификациях

обычных операторов SELECT. Она делает возможным создавать набор буквально из любой комбинации хранимых у вас данных. Вы можете выполнять вычисления и трансформацию множества столбцов и строк в выходной набор. Например, выходные наборы с промежуточными суммами сложно или невозможно получить из динамического набора, но они могут быть быстро и эффективно сгенерированы с помощью хранимых процедур выбора.

Процедуры выбора могут легко генерировать наборы из данных, которые вообще не хранятся в базе данных. Мы все иногда находим применение этой технике. В следующем тривиальном примере список строк, разделенных запятыми, каждая из которых содержит 20 или менее символов, поступает в качестве входа. Процедура возвращает приложению каждую строку в нумерованном виде:

CREATE PROCEDURE BREAKAPART(

INPUTLIST VARCHAR(1024))

RETURNS (

NUMERO SMALLINT, ITEM VARCHAR (20)

)

DECLARE CHARAC CHAR;

DECLARE ISDONE SMALLINT = 0;

BEGIN

NUMERO = 0;

ITEM = ‘ ‘ ;

WHILE (ISDONE = 0) DO

BEGIN

CHARAC = SUBSTRING (INPUTLI ST FROM 1 FOR 1);

IF (CHARAC = ») THEN

ISDONE = 1;

IF (CHARAC = OR CHARAC = ») THEN

BEGIN

NUMERO = NUMERO + 1;

SUSPEND;

/* Отправляет строку в буфер строк */

ITEM = »;

END

ELSE

ITEM = ITEM || CHARAC;

INPUTLIST = SUBSTRING(INPUTLIST FROM 2);

END

END ^

COMMIT;

/* */

SELECT * FROM BREAKAPART (‘ ALPHA, BETA, GAMMA, DELTA ‘) ;

NUMERO ITEM

1 ALPHA

2 BETA

3 GAMMA

4 DELTA

Выигрыш в производительности для сложных наборов

Часто сложные запросы, включающие множество соединений или подзапросов, бывают слишком медленными, чтобы удовлетворить интерактивные приложения. Некоторые запросы могут быть медленными по причине непропорциональности индексов внешних ключей. Поскольку есть возможность оперировать с наборами во внутренних циклах, хранимые процедуры способны создавать требуемые наборы гораздо быстрее и к тому же начинаются возвращать строки раньше, чем позволяют обычные последовательности SQL.

Техника

Техника извлечения и манипулирования данными выходного набора использует курсор для чтения по порядку каждой строки из оператора SELECT В предварительно объявленный набор переменных. Часто это могут быть выходные аргументы, куда помещаются значения столбцов, однако это могут быть и локальные переменные. Внутри цикла с переменными выполняются действия соответствующим образом: преобразовываются для вычислений, если необходимо, или используются как аргументы поиска для вложенных циклов, чтобы получать данные из других запросов. В конце цикла, когда все выходные аргументы получают конечные значения, оператор SUSPEND приводит к паузе в выполнении, пока этот набор передается в кэш строк. Выполнение возобновляется, когда вызывается следующая пересылка.

Как мы видели в предыдущем примере BREAKAPART, оператор SUSPEND является тем элементом, который заставляет процедуру передавать строку.

Конструкция FOR SELECT … DO

Для поиска множества строк в процедуре мы используем конструкцию FOR SELECT … DO. Ее синтаксис:

FOR

<выражение-выбора>

INTO <:переменная [, :переменная [, …]] DO

<составной-оператор>;

<выражение-выбора> может быть любым запросом выбора, использующим соединения, объединения, просмотры, другие процедуры выбора, вызовы функций и т.д. в любой допустимой комбинации.

Оператор FOR SELECT отличается от стандартного оператора SELECT тем, что требует наличия переменных, в которые помещаются значения столбцов, и спецификации полей.

<составной-оператор> может быть одним оператором SUSPEND или блоком из двух или более операторов. <составной-оператор> может иметь вложенные составные операторы.

FOR SELECT … DO является конструкцией цикла, которая отыскивает строку, заданную в <выражении-выбора>, и выполняет для каждой строки оператор или блок операторов, следующих после DO.

Предложение INTO <переменные> обязательно и должно быть последним^[116].

Обработка в цикле

На рис. 30.2 проиллюстрированы типичные виды деятельности, которые могут выполняться внутри циклов для генерации выхода в хранимой процедуре выбора.

Рис. 30.2. Операции в процедуре выбора

В следующих примерах мы посмотрим на то, как комбинации операций в PSQL могут представить более интересную область SQL.

Простая процедура с вложенными операторами SELECT

Процедура выбора ORG_CHART, которая присутствует в примере базы данных employee, не получает входных аргументов. Она использует цикл FOR … SELECT, чтобы строить набор из ссылающегося на себя соединения таблицы DEPARTMENT и передавать значения столбцов по одной строке за раз набору переменных — некоторые из них локальные, некоторые объявлены как выходные аргументы.

CREATE PROCEDURE ORG_CHART

RETURNS (

HEAD_DEPT CHAR(25),

DEPARTMENT CHAR(25),

MNGR_NAME CHAR (2 0),

TITLE CHAR(5),

EMP_CNT INTEGER )

DECLARE VARIABLE mngr_no INTEGER;

DECLARE VARIABLE dno CHAR(3);

BEGIN

FOR SELECT h.department, d.department, d.mngr_no, d.dept_no

FROM department d

LEFT OUTER JOIN department h ON d.head_dept = h.dept_no

ORDER BY d.dept_no

INTO :head_dept, :department, :mngr_no, :dno

Каждый раз, когда цикл обрабатывает строку, он помещает значение ключа (MNGR_NO) в локальную переменную MNGR_NO. ЕСЛИ эта переменная имеет пустое значение, процедура создает значения для выходных аргументов MNGR_NAME и TITLE. ЕСЛИ же эта переменная имеет значение, она передается как аргумент поиска вложенному запросу к таблице EMPLOYEE, уникально идентифицирующему строку и выделяющему имя и код работы менеджера отдела. Эти значения передаются остальным выходным аргументам.

BEGIN

IF (:mngr_no IS NULL) THEN

BEGIN

mngr_name = ‘—TBH—‘;

title = » ;

END

ELSE

SELECT full_name, job_code

FROM employee

WHERE emp_no = :mngr_no

INTO :mngr_name, :title;

SELECT COUNT (emp_no)

FROM employee

WHERE dept_no = :dno

INTO :emp_cnt;

Когда присвоены все выходные значения для одной строки, оператор SUSPEND передает строку в кэш. Управление передается опять на начало цикла, когда выполнен следующий запрос на

пересылку.

SUSPEND;

END

END^

COMMIT^

Обратите внимание, как аккуратно вложенный запрос обходит ту проблему, которую мы имели с подзапросами в DSQL- мы могли в подзапросе вернуть одно и только одно значение. Если нам нужно много значений, а логика левого соединения не работает, то нам пришлось бы использовать множество подзапросов с множеством наборов алиасов для выделения каждого значения из его курсора.

Вызов процедуры выбора

Синтаксис вызова процедуры выбора очень похож на синтаксис обращения к таблице или к просмотру. Единственным отличием является то, что процедура может иметь входные аргументы:

SELECT <список-столбцов> FROM имя ([аргумент [, аргумент …]])

WHERE <условия-поиска>

ORDER BY <список-упорядочения>;

Имя процедуры должно быть задано.

Правила входных аргументов идентичны правилам для выполняемых процедур — см. ранее разд. «Значения входных аргументов».

<список-столбцов>- разделенный запятыми список из одного или более выходных параметров, возвращаемых процедурой, или * для выбора всех столбцов.

Выходной набор может быть ограничен условиями поиска в предложении WHERE и упорядочен с помощью предложения ORDER BY.

Вызов процедуры ORG_CHART

Эта процедура не имеет входных параметров, следовательно, вызов SELECT выглядит как простой выбор в таблице, а именно:

SELECT * FROM ORG_CHART;

Выбор агрегатных значений из процедур

В дополнение к получению значений из процедуры вы можете использовать агрегатные функции. Например, для использования нашей процедуры с целью отображения количества отделов применяйте следующий оператор:

SELECT COUNT (DEPARTMENT) FROM ORG_CHART;

Аналогично, для отображения с помощью ORG_CHART максимального и среднего количества служащих в каждом отделе используйте следующий оператор:

SELECT

MAX(EMP_CNT),

AVG(EMP_CNT)

FROM ORG CHART;

! ! !

СОВЕТ. Если процедура получит ошибку или исключение, агрегатные функции не вернут правильных значений, поскольку процедура завершается до обработки всех строк.

. ! .

Вложенные процедуры

Хранимая процедура сама может вызывать хранимую процедуру. Каждый раз, когда хранимая процедура вызывает другую хранимую процедуру, такой вызов называется вложенным, потому что он появляется в контексте предыдущего и все еще активного вызова первой процедуры. Хранимая процедура, вызываемая другой хранимой процедурой, называется вложенной процедурой.

Следующая процедура возвращает список пользователей, ролей и привилегированных объектов базы данных с их привилегиями SQL. Внутри процедуры два вложенных вызова другой процедуры. Необходимо начать с определения и подтверждения вложенной процедуры — иначе внешняя процедура выдаст ошибку при подтверждении. Вы всегда должны начинать с нижней части «цепочки» при создании процедур, использующих вложенные процедуры.

Приведенная далее вложенная процедура не выполняет операторов SQL^[117]. Она просто берет непонятную константу из набора, используемого внутренне в Firebird для представления типов объектов, и возвращает строку, более осмысленную для человека:

SET TERM ^;

CREATE PROCEDURE SP_GET_TYPE (

IN_TYPE SMALLINT )

RETURNS (

STRING VARCHAR(7) )

BEGIN

STRING = ‘Unknown’;

IF (IN_TYPE = 0) THEN STRING = ‘Table’;

IF (IN_TYPE = 1) THEN STRING = ‘View’;

IF (IN_TYPE = 2) THEN STRING = ‘Trigger’;

IF (IN_TYPE = 5) THEN STRING = ‘Proc’;

IF (IN_TYPE = THEN STRING = ‘User’;

IF (IN_TYPE = 9) THEN STRING = ‘Field’;

IF (IN_TYPE = 13) THEN STRING = ‘Role’;

END^

COMMIT ^

Теперь о внешней процедуре. Запрашиваемая в ней таблица является системной таблицей RBD$USER_PRIVILEGES. Она использует множество техник манипулирования, включая вызовы внутренней SQL-функции CAST() и внешней функции RTRIMO из стандартной библиотеки внешних функций ib_udf для преобразования элементов CHAR(31) в VARCHAR(31). Мы это делаем, потому что собираемся выполнять конкатенацию некоторых из этих строк и нам не нужны конечные пробелы.

SET TERM ^;

CREATE PROCEDURE SP_PRIVILEGES

RETURNS (

Q_ROLE_NAME VARCHAR (31),

ROLE_OWNER VARCHAR(31),

USER_NAME VARCHAR(31),

Q_USER_TYPE VARCHAR(7),

W_GRANT_OPTION CHAR(1),

PRIVILEGE CHAR(6),

GRANTOR VARCHAR. (31),

QUALIFIED_OBJECT VARCHAR(63),

Q_OBJECT_TYPE VARCHAR(7) )

DECLARE VARIABLE RELATION_NAME VARCHAR(31);

DECLARE VARIABLE FIELD_NAME VARCHAR(31);

DECLARE VARIABLE OWNER_NAME VARCHAR(31);

DECLARE VARIABLE ROLE_NAME VARCHAR(31);

DECLARE VARIABLE OBJECT_TYPE SMALLINT;

DECLARE VARIABLE USF,R_TYPE SMALLINT;

DECLARE VARIABLE GRANT_OPTION SMALLINT;

DECLARE VARIABLE IS?ROLE SMALLINT;

DECLARE VARIABLE IS_VIEW SMALLINT;

BEGIN

Вначале мы создадим цикл по таблице RBD$USER_PRIVILEGES, выделяя и направляя некоторые значения прямо в выходные аргументы, а другие в локальные переменные:

FOR SELECT

RTRIM(CAST(RDB$U3ER AS VARCHAR(31))),

RDS$USER_TYPE,

RTRIM (CAST (RDB$GRANTOR AS VARCHAR (31) ) ) ,

RTRIM (CAST (RDB$RELATION_NAME AS VARCHAR (31) )) , RTRIM(CAST(RDB$FIELD_NAME AS VARCHAR (31))) ,

RDB$OBJECT_TYPE,

RTRIM(CAST(RDB$PRIVILEGE AS VARCHAR(31))),

RDB $GRANT OPTION

FROM RDB$USER_PRIVILEGES

INTO : USER_NAME, :USER_TYPE, : GRANTOR, : RELATION_NAME,

FIELD_NAME, : OBJECT_TYPE, : PRIVILEGE, : GRANT_OPTION

Взяв текущее значение выходной переменной USER_NAME, мы обращаемся к RDB$ROLES для получения владельца роли и имени роли в случае, когда «пользователь» текущей строки фактически является ролью. Если же это не роль, то эти поля будут представлены на выходе в виде пунктира:

DO BEGIN

SELECT

RTRIM (CAST (RDB$OWNER_NAME AS VARCHAR ( 31))) , RTRIM(CAST(RDB$ROLE_NAME AS VARCHAR(31)))

FROM RDB$ROLES

WHERE RDB$ROLE_NAME = : USER_NAME

INTO :ROLE_OWNER, : ROLE_NAME;

IF (ROLE_NAME IS NOT NULL) THEN

Q_ROLE_NAME = ROLE_NAME;

ELSE

BEGIN

Q_ROLE_NAME = ‘-‘;

ROLE_OWNER = ‘-‘;

END

WITH GRANT OPTION является специальной привилегией, о которой мы хотим сообщить в нашем выводе. Следовательно, мы преобразуем этот атрибут в ‘Y’, если атрибут присутствует (1), или в пробел, если отсутствует:

IF (GRANT_OPTION = 1) THEN

W_GRANT_OPTION = ‘Y’;

ELSE

W_GRANT_OPTION = »;

Теперь другой запрос к RDB$ROLES, на этот раз для поиска объекта, к которому применяется привилегия роли. Если такой найден, мы добавляем к имени этого объекта полезный префикс. Если это не роль, мы проверяем, является ли наш объект столбцом таблицы, и присваиваем его имени квалификатор.

IS_ROLE = NULL;

SELECT 1 FROM RDB$ROLES

WHERE RDB$ROLE_NAME = :RELATION_NAME

INTO :IS_ROLE;

IF (IS_ROLE = 1) THEN

QUALIFIED_OBJECT = ‘(Role) ‘ ||RELATION_NAME;

ELSE

BEGIN

IF (

(FIELD_NAME IS NULL)

OR (RTRIM(FIELD_NAME) = »)) THEN

FIELD_NAME = ‘ ‘;

ELSE

FIELD_NAME = ‘.’|| FIELD_NAME;

QUALIFIED_OBJECT = RELATION_NAME || FIELD_NAME;

END

В RBD$USER_PRIVILEGES и таблицы, и просмотры имеют тип объекта 0. Это не слишком хорошо для нас, значит, следующий запрос проверяет по таблице RDB$RELATIONS, является ли этот конкретный объект просмотром:

IF (OBJECT_TYPE = 0) THEN

BEGIN

IS_VIEW = 0;

SELECT 1 FROM RDB$RELATIONS

WHERE RDB$RELAT | ON_NAME = : RELATION_NAME

AND RDB$VIEW_SOURCE IS NOT NULL

INTO :IS_VIEW;

IF (IS_VIEW = 1) THEN

OBJECT_TYPE = 1;

END

В этой точке нашего цикла мы получили почти все, что хотели. Однако наш объект все еще имеет свой внутренний номер, и мы все еще не знаем тип «пользователя». Пользователями могут быть не только люди. Именно здесь мы выполняем вложенные вызовы для выполнения трансляции внутренних номеров в осмысленные строки. Когда мы это сделаем, наша запись готова к выводу в кэш строк, и мы вызываем SUSPEND для завершения цикла.

Возвращаемые значения

Вызовы вложенных процедур из триггеров или хранимых процедур почти идентичны вызовам, которые мы используем в DSQL. Синтаксис отличается только там, где мы обрабатываем возвращаемые значения. В DSQL сервер передает возвращаемые значения клиенту в виде структуры записи. В хранимых процедурах мы используем ключевое слово PSQL RETURNING_VALUES и предоставляем переменные для получения этих значений.

EXECUTE PROCEDURE SP_GET_TYPE(:OBJECT_TYPE)

RETURNING_VALUES (:Q_OBJECT_TYPE);

EXECUTE PROCEDURE SP_GET_TYPE (:USER_TYPE)

RETURNING_VALUES (:Q_USER_TYPE);

SUSPEND;

END

END^

Вызов процедуры

Вот еще один простой вызов:

SELECT * FROM SP PRIVILEGES;

Если нам не нужны все столбцы или хотим получить их в особом порядке, мы можем сделать это. Предположим, мы просто хотим посмотреть привилегии всех пользователей-людей, отличных от SYSDBA:

SELECT

USER_NAME,

QUALIFIED_OBJECT,

PRIVILEGE

FROM SP_PRIVILEGES

WHERE Q_USER_TYPE = ‘User’

AND USER_NAME <> ‘SYSDBA’

ORDER BY USER_NAME, QUALIFIED_OBJECT;

Могут быть использованы заменяемые параметры поиска:

SELECT

USER_NAME,

QUALIFIED_OBJECT,

PRIVILEGE

FROM SP_PR1VILEGES

WHERE Q_USER_TYPE = ?

ORDER BY USER_NAME, QUALIFIED_OBJECT;

! ! !

СОВЕТ. Вы можете найти эту процедуру полезной для проверки привилегий SQL в вашей базе данных. Информацию об установке привилегий см. в главе 35.

. ! .

Процедура с промежуточными итогами

В этой процедуре мы обрабатываем записи таблицы SALES базы данных EMPLOYEE. Мы получим два итога: один для каждого вида продаж, а другой — для всех продаж. В качестве входа мы просто используем начальную и конечную даты для группы интересующих нас продаж.

SET TERM ^;

CREATE PROCEDURE LOG_SALES (

.START_DATE DATE,

END_DATE DATE)

RETURNS (REP_NAME VARCHAR (37) ,

CUST VARCHAR(25),

ORDDATE TIMESTAMP,

ITEMTYP VARCHAR(12),

ORDTOTAL NUMERIC(9,2),

REPTOTAL NUMERIC(9,2),

RUNNINGTOTAL NUMERIC(9, 2))

DECLARE VARIABLE CUSTNO INTEGER;

DECLARE VARIABLE REP SMALLINT;

DECLARE VARIABLE LASTREP SMALLINT DEFAULT -99;

DECLARE VARIABLE LASTCUSTNO INTEGER DEFAULT -99;

BEGIN

RUNNINGTOTAL = 0.00;

FOR SELECT

CUST_NO,

SALES_REP,

ORDER_DATE,

TOTAL_VALUE,

ITEM_TYPE

FROM SALES

WHERE ORDER_DATE BETWEEN : START_DATE AND :END_DATE + 1

ORDER BY 2, 3

INTO :CUSTNO, : REP, : ORDDATE, :ORDTOTAL, : ITEMTYP

Заметьте, что мы используем упорядоченный набор. Если вы получаете виртуальную таблицу из хранимой процедуры выбора и вам нужен упорядоченный набор, полезно сделать набор упорядоченным внутри кода процедуры. Оптимизатор может улучшить здесь производительность, если существуют полезные индексы, в то время как упорядочение, применяемое к выходному набору, не может использовать индексов по своей природе.

Внутри цикла мы начинаем использовать данные для нашей строки и для получения итогов. Мы используем немного магии, чтобы избежать повторений имени — это выглядит изящнее при отображении только для чтения — хотя вы не должны делать этого, если вашему приложению нужно получить строки в произвольном порядке и оно использует этот столбец в качестве ключа поиска! Мы управляем именем покупателя похожим образом для исключения ненужного поиска, когда тот же покупатель появляется в последовательных записях.

BEGIN

IF(REP = LASTREP) THEN

BEGIN

REPTOTAL = REPTOTAL + ORDTOTAL;

REP_NAME = «» ;

END

ELSE

BEGIN

REPTOTAL = ORDTOTAL;

LASTREP = REP;

SELECT FULL_NAME FROM EMPLOYEE

WHERE EMP_NO = :REP

INTO :REP_NAME;

END

IF (CUSTNO <> LASTCUSTNO) THEN

BEGIN

SELECT CUSTOMER FROM CUSTOMER

WHERE CUST_NO = :CUSTNO

INTO :COST;

LASTCUSTNO = CUSTNO;

END

RUNNINGTOTAL = RUNNINGTOTAL + ORDTOTAL;

SUSPEND;

Теперь наша строка готова и отправляется в кэш строк вместе с двумя обновленными итогами.

END

END^

SET TERM ;^

Вызов процедуры

Наши входные аргументы имеют тип данных DATE- начальная дата и конечная дата. Процедура отыскивает тип данных TIMESTAMP для выборки строк для курсора. Она добавляет один день к конечной дате, чтобы гарантировать получение каждой строки вплоть до конца этого дня. Это упрощает дела: когда мы вызываем процедуру, нам нужно только предоставить первую и последнюю даты при отсутствии беспокойства по поводу записей с датой более поздней, чем полночь последнего дня.

Следующий вызов возвращает целую таблицу:

SELECT * FROM LOG_SALES (‘16.05.1970’, CURRENT_3ATE);

Мы можем обратиться к процедуре с использованием параметров:

SELECT * FROM LOG_SALES (?, ?);

Просмотр массива в хранимой процедуре

Если в таблице есть столбцы, определенные как массивы, вы не сможете просмотреть данные в таком столбце в простом операторе SELECT, потому что в таблице хранится только идентификатор массива. Хранимая процедура может быть использована для отображения значений массива, если размерность и тип данных столбца массива заранее известны.

Таблица JOB В примере базы данных имеет столбец LANGUAGE REQ, содержащий требуемые языки. Столбец определен как массив из пяти элементов VARCHAR(15).

Следующий пример использует хранимую процедуру для просмотра содержимого этого столбца. Процедура использует цикл FOR … SELECT для поиска каждой строки из таблицы JOB, где столбец LANGUAGE_REQ не является пустым. Затем цикл WHILE отыскивает каждый элемент массива и возвращает значение вызвавшему приложению.

SET TERM ^;

CREATE PROCEDURE VIEW_LANGS

RETURNS (

code VARCHAR(5) ,

grade SMALLINT,

cty VARCHAR(15),

lang VARCHAR(15))

DECLARE VARIABLE i INTEGER;

BEGIN

FOR SELECT

JOB_CODE,

JOB_GRADE,

JOB_COUNTRY

FROM JOB

WHERE LANGUAGE_REQ IS NOT NULL

BEGIN

i = 1;

WHILE (i <= 5) DO

BEGIN

SELECT LANGUAGE_REQ[:i] FROM JOB

WHERE ((JOB_CODE = :code)

AND (JOB_GRADE = :grade)

AND (JOB_COUNTRY = :cty))

INTO :lang;

i =i + 1;

SUSPEND;

END

END ^

SET TERM ; ^

Ее вызов:

SELECT * FROM VIEW_LANGS;

CODE GRADE CTY LANG

Eng 3 Japan Japanese

Eng 3 Japan Mandarin

Eng 3 Japan English

Eng 3 Japan

Eng 4 England English

Eng 4 England German

Eng 4 England French

. . .

Процедура может быть модифицирована таким образом, что будет получать входные аргументы и возвращать другую комбинацию данных в качестве выхода.

Тестирование процедур

Разработчикам не нужно напоминать о необходимости строгого тестирования модулей PSQL, прежде чем передавать их в работу, где они в один скверный день могут принести большой вред. Синтаксический анализатор предупредит вас об ошибках кодирования PSQL, однако как программы ваши модули не защищены от логических ошибок, как и любой код приложения, который вы пишете.

Например, наша процедура LOG SALES прекрасно работает, пока каждая запись продаж имеет непустое значение SALES REP. При этом данный столбец допускает пустое значение. Процедура генерирует результирующий набор, в котором каждая выходная строка зависит от значений в предшествующих строках. Если мы не учтем возможные эффекты появления значения NULL В таком ключе, наша процедура выдаст неверный результат. Позже в этой главе в разд. «Изменение хранимых процедур» мы добавим меры предосторожности при работе, когда могут появиться некоторые проблемы.

Процедуры для совместного использования

Хотя возможно написание процедуры выбора, которая будет выполнять операции по изменению данных в процессе конструирования выходного набора, этого делать не рекомендуется. Хранимая процедура выбора разрабатывается для вывода набора данных клиенту в контексте вызвавшей ее транзакции. Пока клиентское приложение не завершит использование этого выходного набора, транзакция остается неподтвержденной. Если операции DML включены в код, который генерирует выходной набор, эти запросы DML остаются неподтвержденными, пока транзакция не будет завершена клиентом.

В частности, данные могут потенциально сохраняться в несогласованном виде, если значения выхода хранимой процедуры выступают в качестве параметров для операций в других транзакциях.

Изменение хранимых процедур

Firebird 1.0.x предоставляет два способа изменения хранимых процедур с использованием операторов DDL, a Firebird 1.5 добавляет еще и третий. Это:

* оператор ALTER PROCEDURE, который изменяет определение существующей хранимой процедуры, сохраняя ее взаимозависимости с другими объектами;

* оператор RECREATE PROCEDURE, который выполняется, даже если указанная процедура не существует. Если она существует, то эта версия удаляется, а затем заново создается. Существующие зависимости не сохраняются;

* оператор CREATE OR ALTER PROCEDURE (доступен начиная с версии 1.5) предоставляет лучший вариант. Если процедура существует, применяются правила ALTER, зависимости сохраняются. Если не существует, то будет работать точно так же, как и CREATE PROCEDURE.

Любая из этих операций вызовет исключение, если любая попытка изменений разрушает зависимости.

Влияние на приложения

Внутренние изменения процедуры прозрачны всем клиентским приложениям, использующим эту процедуру. Вам не нужно пересоздавать приложения, если изменения не коснулись интерфейса между вызывающей программой и процедурой — тип, количество или порядок выходных или выходных аргументов.

Синтаксис изменения процедур

За исключением ключевого слова, которое вы выбрали для изменения хранимой процедуры, синтаксис для всех операторов такой же, как и для CREATE PROCEDURE. Как и в любом другом компилируемом или интерпретируемом модуле, не существует способов непосредственного изменения элементов без полного пересоздания всего модуля. Каждая «переделка», независимо от выбранного ключевого слова для задания операции, имеет дело с созданием новой версии исходного кода и нового двоично- кодированного объекта.

Синтаксис:

{CREATE | ALTER | RECREATE | CREATE OR ALTER} PROCEDURE Имя

[(переменная тип-данных [,переменная тип-данных …])]

[RETURNS (переменная тип-данных [, переменная тип-данных …])]

тело-процедуры;

ALTER PROCEDURE

В ALTER PROCEDURE имя процедуры должно быть именем существующей процедуры.

Это мягкий способ изменения кода процедуры, потому что если у нее есть зависимости, на которые логически не влияют изменения, то они не будут влиять на структурную часть.

Вообще, не оказывается влияния на зависимости, включающие другие объекты, которые зависят от измененной процедуры. При этом, если изменения хранимой процедуры изменяют определения ее входных и выходных аргументов, нужно будет выполнить RECREATE PROCEDURE для любой другой процедуры, к которой происходит обращение в процессе выполнения.

! ! !

ВНИМАНИЕ! Некоторые версии Firebird 1.0.x обнаруживают ошибку, когда зависимые объекты выдают исключение при перекомпиляции зависимого объекта, даже если изменения не оказывали воздействия на интерфейс между объектами.

. ! .

RECREATE PROCEDURE

Оператор RECREATE PROCEDURE идентичен оператору CREATE PROCEDURE за исключением того, что для существующей процедуры с тем же именем он внутренне выполняет операцию DROP PROCEDURE перед созданием нового двоичного объекта. Имя процедуры не должно существовать.

Вы можете использовать его, как и ALTER PROCEDURE, однако оно не сохраняет существующие зависимости. Операция будет заблокирована, если существуют зависимые объекты (просмотры или другие процедуры, которые ссылаются на данную процедуру).

Процедура не обязательно должна существовать, однако будьте внимательны с чувствительностью к регистру в именах объектов, если при создании процедуры используются идентификаторы, заключенные в апострофы. Предположим, вы создаете следующую процедуру:

CREATE PROCEDURE «Try_Me»

RETURNS (AWORD VARCHAR(10))

BEGIN

AWORD = ‘turtle’;

END ^

Теперь вы решаете изменить ее с использованием RECREATE PROCEDURE:

RECREATE PROCEDURE Try_Me

RETURNS (AWORD VARCHAR(10))

BEGIN

AWORD = ‘Venezuela’;

END ^

Исходная процедура с именем, чувствительным к регистру Try_Me, сохраняется неизмененной. «Заново созданная» процедура является новой процедурой с именем, не чувствительным к регистру — TRY_ME.

CREATE OR ALTER PROCEDURE

Новый в версии 1.5 синтаксис создает новую процедуру, если не существует процедуры с тем же именем, иначе изменяет ее.

Исправление процедуры LOG_SALES

Как пример, мы собираемся исправить процедуру LOG_SALES, которая обещает доставить нам неприятности, потому что мы не обратили внимание на пустые значения ключей. Вот блок, который может решить проблемы:

CREATE PROCEDURE LOG_SALES ( . . .

. . .

BEGIN

IF(REP = LASTREP) THEN

/* будет иметь значение false, если оба значения null */

BEGIN

REPTOTAL = REPTOTAL + ORDTOTAL;

REP_NAME = «» ;

END

ELSE

BEGIN

REPTOTAL = ORDTOTAL;

LASTREP = REP;

SELECT FULL_NAME FROM EMPLOYEE

WHERE EMP_NO = :REP

INTO :REP_NAME;

/* вернет null, если переменная REP имеет значение null */

END

. . .

END ^

Мы исправили логику для обработки пустых значений (сгруппированных вместе в конце курсора, потому что набор упорядочен по этому столбцу) и используем операторы CREATE или ALTER для изменения кода:

CREATE OR ALTER PROCEDURE LOG_SALES (…

. . .

BEGIN

* ************ */

IF((REP = LASTREP) OR (LASTREP IS NULL)) THEN

/* ************ */

BEGIN

REPTOTAL = REPTOTAL + ORDTOTAL;

REP_NAME = «» ;

END

ELSE

BEGIN

REPTOTAL = ORDTOTAL;

LASTREP = REP;

/* ************* */

IF (REP IS NOT NULL) THEN

SELECT FULL_NAME FROM EMPLOYEE

WHERE EMP_NO = : REP

INTO :REP_NAME;

ELSE

REP_NAME = ‘ Onassigned ‘ ;

/* ************* */

END

. . .

END ^

COMMIT ^

Ошибка «Объект находится в использовании»

Подтверждение изменения вызовет пресловутую ошибку (обсуждавшуюся в предыдущей главе), если какой-нибудь пользователь в настоящий момент использует эту процедуру или любой другой объект, зависящий от нее. Даже если мы уберем это препятствие, новая версия процедуры не станет немедленно доступной в Суперсервере, если старая версия все еще находится в кэше. Все пользователи должны отключиться от базы данных, а когда они снова к ней подключатся, они смогут увидеть новую версию.

В Классическом сервере новая версия будет доступна следующему клиенту, который соединится с базой данных.

Удаление хранимых процедур

Оператор DROP PROCEDURE удаляет существующую хранимую процедуру из базы данных. Вы можете использовать этот оператор везде, где можно использовать операторы DDL.

! ! !

ПРИМЕЧАНИЕ. Операторы DDL не могут выполняться как операторы PSQL. При этом в Firebird 1.5 оператор DDL может передаваться через конструкцию EXECUTE STATEMENT. Нужно ли читающему пользователю быть осторожным в отношении использования EXECUTE STATEMENT при удалении самой процедуры?

. ! .

Синтаксис:

DROP PROCEDURE имя;

имя процедуры должно быть именем существующей процедуры. Будьте внимательны в отношении чувствительности к регистру имен объектов, если при создании процедуры были использованы идентификаторы в апострофах.

Следующий оператор удаляет процедуру LOG_SALES:

DROP PROCEDURE LOG_SALES;

Ограничения

При удалении процедуры существуют ограничения.

* Только пользователь SYSDBA и владелец процедуры могут ее удалять.

* Процедура, находящаяся в использовании в любой другой транзакции, не может быть удалена. Это является особой проблемой в системах, где процедуры вызываются в транзакциях, которые подтверждаются с использованием

CommitRetaining.

* Если другие объекты ссылаются или вызывают данную процедуру, то необходимо сначала изменить зависимые объекты, удалив такие ссылки и подтвердив работу, прежде чем удалять процедуру.

* Для удаления рекурсивной процедуры необходимо сначала удалить рекурсивные вызовы и подтвердить изменения. Похожие трудности существуют и для процедуры, вызывающей другую процедуру, которая в свою очередь вызывает процедуру, которую вы собираетесь удалить. Все подобные зависимости должны быть удалены и подтверждены, чтобы процедура стала доступной для удаления.

Тема оптимизации: использование внутренних возможностей

Firebird наследует недокументированную возможность, которая может ускорить выполнение запроса при некоторых условиях. Это RDB$DB_KEY (обычно называется просто db key), внутренний ключ, поддерживаемый сервером базы данных для внутреннего использования при оптимизации запросов и управлении версиями записей. Внутри контекста транзакции, где он используется, он представляет позицию строки в таблице8^[118].

Относительно RDB$DB_KEY

Первый урок заключается в том, что RDB$DB_KEY является прямым указателем, связанным с базой данных, а не с физическим адресом на диске. Второй — значения RDB$DB_KEY не следуют в предсказуемой последовательности. Не используйте вычисления, включающие их относительные позиции! Третий урок в том, что они изменчивы — они изменяются после резервного копирования и последующего восстановления, а иногда и после подтверждения транзакции. Главным является понимание мимолетности db key и отсутствие предположений о его существовании в то время, когда ссылающаяся на него операция завершается или отменяется.

Размер RDB$DB_KEY

Для таблиц RDB$DB_KEY использует 8 байт. Для просмотров он использует коэффициент умножения этих 8 байт, сколько таблиц используется в просмотре. Например, если просмотр соединяет три таблицы, его RDB$DB_KEY использует 24 байт. Это важно, когда вы работаете с хранимыми процедурами и собираетесь сохранять RDB$DB_KEY В переменных. Вы должны использовать тип данных CHAR(n) корректной длины.

По умолчанию db key возвращается в виде шестнадцатеричного числа — две шестнадцатеричные цифры представляют каждый байт: 16 шестнадцатеричных цифр возвращаются для 8 байт. Сделайте для одной из ваших таблиц в isql следующее:

SQL> SELECT RDB$DB_KEY FROM MYTABLE;

RDB$DB KEY

000000B600000002

000000B600000004

000000B600000006

000000B600000008

000000B60000000A

Преимущества

Поскольку RDB$DB KEY напрямую указывает на место хранения записи, он будет быстрее для поиска, чем первичный ключ. Если по каким-то причинам в таблице нет первичного ключа или активного уникального индекса, или уникальный индекс допускает пустые значения, то возможно существование полных дубликатов строк. В этих условиях RDB$DB_KEY является единственным способом точной идентификации каждой строки.

Некоторые виды операций выполняются быстрее в хранимой процедуре при использовании RDB$DB_KEY- обычно в случаях изменения и удаления при сложных условиях. Для добавлений (даже при огромных пакетах) RDB$DB_KEY недоступен, потому что не существует способа определить заранее, какими будут значения.

Однако, если отыскиваемые страницы базы данных для изменения или удаления уже находятся в главной памяти, разница в скорости доступа скорее всего будет незначительной. То же самое верно, если отыскиваемый набор достаточно мал, а все отыскиваемые строки расположены близко друг к другу.

Оптимизация запросов

Проблемы с производительностью, скорее всего, возникнут, если вы попытаетесь запустить изменения DSQL, похожие на следующий пример, для большой таблицы:

UPDATE TABLEA А

SET A.TOTAL = (SELECT SUM (B.VALUEFIELD)

FROM TABLEB В

WHERE B.FK = A.PK)

WHERE <условия…>

Если вы часто выполняете ту же операцию, и она использует много строк, то стоит попытаться написать хранимую процедуру, которая получит соответствующий итог для каждой строки без необходимости выполнять подзапрос:

CREATE PROCEDURE …

. .

BEGIN

FOR SELECT B.FK, SUM(B.VALUEFIELD) FROM TABLEB В

GROUP BY B.FK

INTO :B_FK, : TOTAL DO

UPDATE TABLEA A SET A.TOTAL = :TOTAL

WHERE A.PK = :B_FK

AND …

END

Хотя это и быстрее, тем не менее остается проблема, что записи в А выбираются по первичному ключу каждый раз, когда выполняется проход по циклу FOR … DO.

Некоторые люди получают лучший результат при этом необычном синтаксисе:

. . .

DECLARE VARIABLE DBK CHAR (8);

/* 8 символов для db_key таблицы А */

. . .

FOR SELECT B.FK,

SUM(B.VALUEFIELD) ,

A. RDB$DB_KEY

FROM TABLEB В

JOIN TABLEA A ON A.PK = B.FK

WHERE <условия>

GROUP BY B.FK, A.RDB$DB_KEY

INTO :B_FK, :TOTAL, :DBK DO

UPDATE TABLEA SET A.TOTAL = :TOTAL

WHERE A.RDB$DB_KEY = :DBK;

! ! !

ПРИМЕЧАНИЕ. В Firebird нет необходимости в ключевом столбце для создания соединения, однако он нужен в списке SELECT, чтобы предложение GROUP BY было допустимым.

. ! .

Перечислим преимущества такого подхода.

* Фильтрация общих записей для А и В будет эффективной, когда оптимизатор может создать хороший фильтр для явного соединения.

* Если соединение может применить свое собственное предложение поиска, то существует выгода от выполнения фильтрации до того, как изменение будет проверять свое собственное условие.

* Строки таблицы правой стороны (А), локализованные с помощью прямых указателей db key, выделяются во время соединения быстрее, чем при просмотре первичного ключа или его индекса.

Добавления

Поскольку добавление не включает поиск, наиболее простые операции добавления — например, чтение константных значений из импортируемого набора во внешней таблице — не требуют локализации ключей.

Однако не все входные значения(VALUE2) оператора INSERT получаются так просто.

Это может быть очень сложным набором значений, полученным из выражений, со-

единений или агрегатных операций. В хранимой процедуре операция INSERT может разветвляться в предложении ELSE предиката IF (EXISTS (…)), например:

IF EXISTS(SELECT…) THEN

. . .

ELSE

BEGIN

INSERT INTO TABLEA

SELECT

C.PKEY,

SUM (B. AVALUE) ,

AVG(B.BVALUE),

COUNT(DISTINCT C.XYZ)

FROM TABLEB B JOIN TABLEC С

ON B.X = C.Y

WHERE C.Z = ‘value’

AND С.PKEY NOT IN(SELECT PKEY FROM TABLEA)

GROUP BY С.PKEY;

END

. . .

Реализация этого в хранимой процедуре:

FOR SELECT

С.PKEY,

SUM(B.AVALUE),

AVG(B.BVALUE),

COUNT(DISTINCT C.XYZ)

FROM TABLEB B JOIN TABLEC С

ON B.X = C.Y

WHERE C.Z = ‘value’

AND С.PKEY NOT IN(SELECT PKEY FROM TABLEA)

GROUP BY С.PKEY

INTO :C_KEY, :TOTAL, :B_AVG, :C_COUNT DO

BEGIN

SELECT A.RDB$DBKEY FROM TABLEA A

WHERE A.PKEY = :C_KEY

INTO :DBK;

IF (DBK IS NULL) THEN /* строка не существует */

INSERT INTO TABLEA(PKEY, TOTAL, AVERAGE_B, COUNT_C)

VALUES(:C_KEY, :TOTAL, :B_AVG, :C_COUNT);

ELSE

UPDATE TABLEA SET

TOTAL = TOTAL + :TOTAL,

AVERAGE_B = AVERAGE_B + :B_AVG,

COUNT_C = COUNT_C + :C_COUNT

WHERE A. RDB$DB_KEY = : DBK;

END

Длительность действия

По умолчанию областью действия db key является текущая транзакция. Вы можете считать, что он остается правильным во время действия текущей транзакции. Подтверждение или откат транзакции приведет к тому, что значения RDB$DB_KEY станут непредсказуемыми. Если вы используете commitRetaining, контекст транзакции сохраняется, блокируя сборку мусора и, следовательно, предотвращая «переназначение» старого db_key. При этих условиях значения RDB$DB_KEY для любых используемых строк в вашей транзакции сохраняются действительными, пока не произойдет «жесткое» подтверждение или откат.

После жесткого подтверждения или отката другая транзакция может удалить строку, которая была изолирована внутри контекста вашей транзакции и, следовательно, рассматривалась как «существующая» в вашем приложении. Любое значение RDB$DB_KEY теперь может указывать на несуществующую строку. Если у вас достаточно большой интервал между моментом, когда начинается ваша транзакция и когда завершается ваша работа, вы должны проверять, не была ли за это время строка изменена или заблокирована другой транзакцией.

Некоторые интерфейсы приложений, например IB Objects, являются суперинтеллектуальными в плане добавлений и могут подготовить «сегмент» для вновь добавленных строк в клиентских буферах для быстрого обновления списка после подтверждения. Такие возможности важны для производительности при работе в сети. Однако «интеллектуальность», подобная этой, основывается на точных реальных ключах. Поскольку db_key является просто заменителем ключа для набора, наследуемого от предыдущих подтвержденных данных, он не имеет смысла для новой строки — он не доступен при изменениях в клиентском буфере.

Изменение величины длительности действия

Значение длительности действия по умолчанию для RDB$DB_KEY можно изменить во время соединения с базой данных, используя параметр API isc_dpb_dbkey_scope. Некоторые разработки — например, компоненты IB Objects в инструментах окружения Borland Object Pascal — предоставляют его в классе соединения. Однако не рекомендуется расширять область действия db key в высоко интерактивной среде, поскольку это остановит сборку мусора, приводя к нежелательному росту размера файла базы данных и замедлению работы системы вплоть до ее зависания или краха. Не используйте соединения, имеющие область действия для db key, отличающуюся от значения по умолчанию.

RDB$DB_KEY в многотабличных наборах

Все таблицы поддерживают свои собственные 8-байтовые столбцы RDB$DB_KEY. Просмотры и соединения во время выполнения генерируют db key путем конкатенации RDB$DB_KEY из строк исходных таблиц. Если вы используете RDB$DB_KEY в многотабличных наборах, будьте особенно внимательны при задании каждого из них.

RDB$DB_KEY не может быть использован между различными таблицами. Не существует возможности установить отношения зависимости между RDB$DB_KEY двух таблиц, за исключением реентерабельных (ссылающихся на себя) соединений.

Пора дальше

Многие из техник, описанных в данной главе, применимы к любым модулям PSQL, которые вы создаете. Далее мы сфокусируем наше внимание на техниках и возможностях языка PSQL, которые вы сможете использовать при написании триггеров, автоматически реагирующих на изменение состояния данных в строке или на добавление новой строки.

ГЛАВА 31. Триггеры.

Триггеры — ключевые элементы среди возможностей, предоставляемых Firebird для централизованной реализации бизнес-правил внутри системы управления базой данных. Триггер является автономным модулем, который выполняется автоматически, когда выполняется запрос, который будет изменять состояние данных в таблице.

Для написания кодов триггеров используются техники PSQL и хранимых процедур. При этом триггеры не могут вызываться из приложений или других процедур. Соответственно, они не могут получать входные и возвращать выходные аргументы, как это возможно в процедурах. В дополнение к PSQL они включают некоторые контекстные расширения языка, применимые только в модулях триггеров.

Все триггеры в Firebird выполняются на уровне строки каждый раз, когда изменяется образ строки. Firebird поддерживает высокий уровень детализации при определении времени, последовательности и условий, при которых будет выполняться конкретный модуль триггера. Множество модулей может быть определено для каждой фазы и события.

Триггеры являются частью работы транзакции, в которой событие DML изменяет состояние строки. Если транзакция успешно подтверждается, все действия триггеров будут «приняты». Если будет выполнен откат транзакции, все действия триггера будут отменены.

Фаза, событие и последовательность

Триггер может выполняться в одной из двух фаз, связанных с запрошенными изменениями состояния данных: до (before) записи или после (after) нее. Он может применяться к одному из трех событий DML: добавление, изменение или удаление. Начиная с Firebird 1.5 возможно объединение действий триггера для двух или трех событий DML в одном модуле триггера до или после.

Фаза и событие

В табл. 31.1 представлены восемь типов модулей триггеров.

Таблица 31.1. Комбинации фаза/событие для модулей триггеров

Вид триггера	Описание	Версия
BEFORE INSERT	Вызывается до создания новой строки. Позволяет изменять входные значения	Все
AFTER INSERT	Вызывается после создания новой строки. Не позволяет изменять входные значения. Обычно используется для модификации других таблиц	Все
BEFORE UPDATE	Вызывается до создания новой версии записи. Позволяет изменять входные значения	Все
AFTER UPDATE	Вызывается после создания новой версии записи. Не позволяет изменять входные значения. Обычно используется для изменения других таблиц	Все
BEFORE DELETE	Вызывается до удаления существующей строки. Не принимает изменений никаких столбцов в строке	Все
AFTER DELETE	Вызывается после удаления строки. Не принимает изменений никаких столбцов в строке. Обычно используется для модификации других таблиц	Все
BEFORE <событие> OR <событие> [OR <событие>]	Вызывается до выполнения изменения любого требуемого состояния данных. Действия для события DML должны быть закодированы условно. Действие «Удаление» не может изменять никакие столбцы в строке	1.5+
AFTER <событиё> OR <событие> [OR <событие>]	Вызывается после выполнения изменения любого требуемого состояния данных. Действия для события DML должны быть закодированы условно. Действия не могут изменять никакие столбцы в строке. Обычно используется для модификации других таблиц	1.5+

Последовательность

Для любой комбинации фаза/событие Firebird позволяет использовать множество триггеров. Вероятно, существует какое-то практическое ограничение, однако можно с уверенностью сказать, что вы можете создавать столько триггеров, сколько вам нужно с использованием целых чисел от 0 до 32 767. Последовательный номер по умолчанию (POSITION) ноль. Хорошей практикой является задание для триггера порядка выполнения, однако явное указание последовательности не является обязательным. Если присутствуют последовательные номера, триггеры будут выполняться в возрастающем порядке. Числа не должны быть уникальными, последовательность может иметь разрывы.

Набор триггеров для фазы/события со значением по умолчанию POSITION 0 будет выполняться в алфавитном порядке их имен. То же самое можно ожидать, если вы имеете группу триггеров, имеющих один и тот же не нулевой последовательный номер.

Следующий пример демонстрирует, как будут выполняться четыре триггера изменения (UPDATE) для таблицы ACCOUNT:

CREATE TRIGGER BU_ACC0UNT5 FOR ACCOUNT

ACTIVE BEFORE UPDATE POSITION 5 AS …

CREATE TRIGGER BU_ACCOUNTO FOR ACCOUNT

ACTIVE BEFORE UPDATE POSITION 0 AS …

CREATE TRIGGER AU_ACCOUNT5 FOR ACCOUNT

ACTIVE AFTER UPDATE POSITION 5 AS …

CREATE TRIGGER AU_ACCOUNT3 FOR ACCOUNT

ACTIVE AFTER UPDATE POSITION 3 AS …

Кто-то изменяет некоторые строки в таблице ACCOUNT:

UPDATE ACCOUNT SET С =’CANCELED’ WHERE C2 = 5;

Вот последовательность событий для каждой изменяемой строки:

1. Выполняется триггер BU_ACCOUNTO.

2. Выполняется триггер BU_ACCOUNTS.

3. Новая версия записи записывается на диск.

4. Выполняется триггер AU_ACCOUNT3.

5. Выполняется триггер AU_ACCOUNT5.

Состояние

Триггер может быть активным (active) или неактивным (inactive). Запускаются только активные триггеры. См. замечания к ALTER TRIGGER по поводу подробностей деактивации триггера.

Создание триггеров

Триггер определяется с помощью оператора CREATE TRIGGER, который состоит из заголовка и тела. Заголовок триггера отличается от заголовка хранимой процедуры, он содержит:

* имя триггера, которое должно быть уникальным в базе данных;

* имя таблицы, идентифицирующее таблицу, с которой ассоциируется триггер;

* атрибуты, которые определяют состояние, фазу, событие DML и, необязательно, последовательность.

Тело триггера, как и тело хранимой процедуры, содержит:

* необязательный список локальных переменных и их типов данных;

* блок операторов на языке процедур и триггеров Firebird, заключенный в операторные скобки BEGIN и END. Эти операторы выполняются, когда запускается триггер. Сам блок может включать другие блоки, так что может существовать много уровней вложенности.

Синтаксис

Для всех версий Firebird синтаксис CREATE TRIGGER одинаков:

CREATE TRIGGER имя FOR {таблица | просмотр}

[ACTIVE | INACTIVE]

{BEFORE | AFTER} {DELETE | INSERT | UPDATE}

[POSITION число]

AS <тело-триггера> ^

<тело-триггера> = [<список-объявления-переменных>] <блок>

<список-объявления-переменных> = DECLARE VARIABLE переменная тип-данных;

[DECLARE [VARIABLE] переменная тип-данных; …]

<блок> =

BEGIN

<составной-оператор> [<составной-оператор> …]

END

<составной-оператор> = <блок> | оператор;

В версии 1.5 возможно слияние всех событий в один триггер фазы:

CREATE TRIGGER имя FOR {таблица | просмотр}

[ACTIVE | INACTIVE]

{BEFORE | AFTER}

{DELETE OR {[INSERT [OR UPDATE]} | {INSERT OR [. . ]} | {UPDATE OR [..]}}

[POSITION число]

AS <тело-триггера> ^

Элементы заголовка

Все, предшествующее предложению AS, является заголовком триггера. Заголовок должен задавать уникальное имя триггера и имя существующей подтвержденной таблицы или просмотра, кому принадлежит триггер.

Именование триггеров

Синтаксис требует, чтобы имя триггера было уникальным среди всех имен триггеров в базе данных. Хорошей практикой является применять некоторые соглашения для именования триггеров, которые имеют смысл для вас и очевидны для всех других, кто будет работать с вашей базой данных. Автор использует «формулу» для идентификации фазы и события (BI | AI | BU | AU | BD | AD | BA | AA — два последних представляют «до всех», Before All и «после всех», After All), имя таблицы и номер в последовательности, если нужно^[119]. Например, триггер до добавления для таблицы CUSTOMER может быть назван BI_CUSTOMERI.

CREATE TRIGGER BI CUSTOMERl FOR CUSTOMER…

Атрибуты триггера

Перечислим остальные атрибуты заголовка триггера.

* Состояние триггера, ACTIVE или INACTIVE, определяющее, будет ли триггер запускаться после его создания. Значение по умолчанию ACTIVE. Деактивация триггера полезна при разработке и отладке.

* Индикатор фазы, BEFORE или AFTER, определяющий момент, когда триггер будет выполняться при событии DML.

* Индикатор события DML определяет тип операции SQL, при которой будет выполняться триггер: INSERT, UPDATE или DELETE.

* В Firebird 1.0.x может быть указан индикатор ровно одного события. Начиная с версии 1.5, необязательное расширение <событие> OR <событие> … позволяет задавать два или три события в одном модуле. Например, … BEFORE INSERT OR UPDATE OR DELETE … позволяет вам задать действия для всех трех событий. Логические контекстные переменные INSERTING, UPDATING или DELETING поддерживают логику переходов.

* Необязательный индикатор последовательности, POSITION число, определяет момент запуска триггера по отношению к другим триггерным модулям для той же фазы и события.

Тело триггера

Во всех кодах модулей Firebird тело состоит из необязательного объявления списка локальных переменных, за которым следует блок операторов. Программирование тела триггера в точности такое же, как и программирование тела процедуры (см. главу 30). Интерес для нас в этой главе представляют некоторые специальные расширения PSQL, осуществляющие поддержку контекста триггера, и некоторые особые роли триггеров по реализации и поддержке бизнес-правил.

Триггеры могут вызывать хранимые процедуры. Правила вызова для триггеров в точности такие же, что и для хранимых процедур. Техники обработки исключений обсуждаются в главе 32.

Триггеры могут использовать курсоры, выполнять операции с другими таблицами и отправлять события. Они могут вызывать и обрабатывать исключения, включая те, которые возникли во вложенных процедурах.

Триггеры никогда не вызываются процедурами, другими триггерами или приложениями. Они совсем не поддерживают входные и выходные аргументы.

Особенности PSQL для триггеров

Два особых элемента PSQL доступны триггерам: логические контекстные переменные событий INSERTING, UPDATING и DELETING и контекстные переменные NEW и OLD.

Переменные события

В Firebird появляются логические контекстные переменные INSERTING, UPDATING и DELETING, чтобы поддерживать условные переходы для триггеров, используемых для нескольких событий. Возможным синтаксисом ветвления может быть:

IF ({INSERTING | UPDATING | DELETING}

OR {UPDATING | DELETING | INSERTING}

[OR {DELETING | INSERTING | UPDATING}]) THEN …

Работа этих полезных предикатов иллюстрируется в дальнейших примерах этой главы.

Переменные NEW и OLD

Контекстные переменные NEW и OLD являются расширениями PSQL, специфичными для триггеров^[120]; они позволяют ссылаться на существующие («старые») и требуемые («новые») значения каждого столбца. Переменные NEW.* имеют значения в событиях INSERT и UPDATE; переменные OLD.* имеют значения в событиях UPDATE и DELETE, NEW.* в событиях удаления и OLD.* В событиях добавления имеют значение NULL. Применимые значения NEW и OLD доступны для всех столбцов таблицы или просмотра, даже если сами столбцы не указаны в операторе DML.

Значения OLD.* (если доступны) могут использоваться в триггерах как переменные, но изменение значения не влияет на сохраненное старое значение^[121]. Значения NEW.* (если доступны) могут использоваться для чтения/записи в фазе BEFORE и только для чтения в фазе AFTER. Если вы хотите манипулировать ими как переменными значениями в триггере AFTER, присвойте их значения локальным переменным и обращайтесь к этим локальным переменным.

Использование NEW и OLD

Для использования мощи триггеров Firebird в разработке баз данных при отслеживании целостности данных, независимо от людей и внешних программ, переменные NEW и OLD являются основным инструментом. Они могут быть использованы для:

* получения допустимых значений по умолчанию в некоторых условиях;

* проверки и при необходимости преобразования входных данных пользователя;

* получения ключей и значений для выполнения автоматических обновлений в других таблицах;

* реализации автоинкрементных ключей средствами генераторов.

Новые значения для строки могут быть изменены только в действиях BEFORE. Если триггер, запускаемый в фазе AFTER, попытается присвоить значение столбцу NEW, это не даст

никакого результата.

Все значения NEW можно перезаписывать в фазе BEFORE, они немедленно принимают новые назначенные им значения. Новая версия записи получит переназначенные значения, только когда все триггеры BEFORE будут завершены. С этого момента значения NEW становятся значениями только для чтения. Следовательно, если у вас несколько триггеров изменяют одни и те же значения NEW, важно, чтобы все они имели различные номера POSITION, правильно упорядоченные.

Реализация автоинкрементных ключей

Рекомендованное использование в Firebird триггеров BEFORE INSERT — реализация в стиле @IDENTITY автоинкрементных первичных ключей. Эта техника проста, и большинство разработчиков Firebird могут написать такие триггеры во сне. Она включает два шага:

1. Создание генератора для генерации уникальных чисел ключа.

2. Написание триггера BEFORE INSERT для таблицы.

Для иллюстрации этой техники мы реализуем автоинкрементный первичный ключ для таблицы CUSTOMER, у которой первичный ключ CUSTOMER_ID- столбец целого типа BIGINT (версия 1.5) или NUMERIC(18,0) (версия 1.0.x). В диалекте 1 базы данных CUSTOMER_ID должен иметь тип INTEGER.

Во-первых, создадим генератор:

CREATE GENERATOR GEN_PK_CUSTOMER;

Затем создадим триггер:

CREATE TRIGGER BI_CUSTOMER FOR CUSTOMER

ACTIVE BEFORE INSERT POSITION 0

BEGIN

IF (NEW.CUSTOMER_ID IS NULL) THEN

NEW. CUSTOMER_ID = GEN_ID (GEN_PK_CUSTOMER, 1) ;

END ^

COMMIT ^

Когда выполняется добавление, CUSTOMER ID сознательно не указывается во входном списке оператора INSERT:

INSERT INTO CUSTOMER (

LAST_NAME,

FIRST_NAME,

…)

VALUES (?, ?, …);

Без триггера этот оператор вызовет исключение, потому что первичный ключ не может иметь пустого значения. Однако триггер BEFORE INSERT выполняется до проверки этого ограничения, он контролирует, что CUSTOMER ID имеет пустое значение, и выполняет свое действие.

Зачем проверять NEW.значение на NULL

Если триггер может делать это для меня, то вы можете спросить, зачем нужно выполнять проверку на NULL?

Для приложения может быть полезным знать, какое будет значение первичного ключа новой строки без необходимости ожидать завершения транзакции. Например, это общее требование при создании «главной» записи и связи с ней «подчиненных» записей обычно с помощью внешнего ключа в одной транзакции. Довольно неуклюже — а иногда и рискованно — нарушать атомарность задачи создания главная- подчиненная, подтверждая создание главной для получения необходимого вам значения внешнего ключа для подчиненных записей, полагаясь только на триггер.

Приложения, написанные для Firebird, имеют преимущества, благодаря одной особой характеристике генераторов: они не зависят от пользовательских транзакций. Однажды сгенерированное значение не может быть выдано ни одной другой транзакции и не может быть отменено.

Быстрый запрос в его собственной транзакции^[122] возвращает значение

SELECT GEN_ID (GEN_PK_CUSTOMER, 1) AS RESULT

FROM RDB$DATABASE;

Если в вашем триггере опущена проверка на пустое значение и просто выполняется:

. . .

NEW.CUSTOMER_ID = GEN_ID (GEN_PK_CUSTOMER, 1);

END ^

то значение, полученное приложением, будет перекрыто вторым «дерганьем» генератора, что нарушит связь с подчиненными записями.

Эта ситуация не является аргументом в пользу генерации ключей только в триггерах. Наоборот, триггер с проверкой на NULL обеспечивает реализацию бизнес-правил при любых условиях.

! ! !

ВНИМАНИЕ! В разработках, где нет хорошей интеграции работы приложений различных разработчиков, или где пользователи имеют свободный доступ к базе данных при использовании инструментов запросов, может оказаться необходимым включение в ваши триггеры более высокого уровня защиты целостности ключей, такого как контроль принадлежности диапазону или другая подходящая форма проверки.

. ! .

Преобразования

Переменная NEW может быть использована для преобразования значения в нечто другое. Общий трюк заключается в использовании триггера (или пары триггеров в версии 1.0.А-) для поддержания «заменителя» столбца для выполнения нечувствительных к регистру поисков по другому столбцу, который может содержать смешанные значения регистра. Триггер читает значение NEW столбца со смешанным регистром, конвертирует его в верхний регистр и записывает в значение NEW столбца поиска. Такой столбец-«заменитель» должен иметь ограничение NOT NULL для гарантии того, что в нем всегда будет значение для поиска:

CREATE TABLE MEMBER (

MEMBER_ID INTEGER NOT NULL PRIMARY KEY,

LAST_NAME VARCHAR (40) NOT NULL,

FIRST_NAME VARCHAR (35),

PROXY_LAST_NAME VARCHAR (40),

MEMBER_TYPE CHAR(3) NOT NULL,

MEMBERSHIP_NUM VARCHAR(13) ,

. . . . );

COMMIT;

/* */

SET TERM ^;

CREATE TRIGGER BA_MEMBER1 FOR MEMBER

ACTIVE BEFORE INSERT OR UPDATE

POSITION 0

BEGIN

. . .

NEW. PROXY_LAST_NAME = UPPER(NEW.LAST_HAME) ;

. . .

END ^

Возможны любые виды преобразований. Предположим, мы хотим получить количество элементов (MEMBERSHIP_NUM), собранное из MEMBER_TYPE, за которым следует строка из десяти цифр, заполненная слева нулями и полученная из сгенерированного первичного ключа таблицы MEMBER. С помощью автоматической генерации в триггере BEFORE INSERT мы можем это осуществить^[123]:

CREATE TRIGGER BI_MEMBER2 FOR MEMBER

ACTIVE BEFORE

INSERT POSITION 2

DECLARE VARIABLE ID AS STRING VARCHAR (10);

BEGIN

ID_AS_STRING = CAST (NEW. ID AS VARCHAR (10)) ;

WHILE (NOT (ID_AS_STRING LIKE ‘ %’))

/* 10-символьная маска */

ID_AS_STRING = ‘0’ || ID_AS_STRING;

NEW.MEMBERSHIP_NUM = NEW.MEMBER_TYPE || ID_AS_STRING;

END ^

Проверка и значения по умолчанию

Триггеры могут улучшить стандартные ограничения SQL, когда они используются для проверки входных данных и применения значений по умолчанию.

Проверка

SQL предоставляет ограничения CHECK для гарантии того, что будут сохраняться только «хорошие» данные. Например, значения столбцов, создаваемых на основе следующего домена, ограничены символами в верхнем регистре и цифрами:

CREATE DOMAIN TYPECODE CHAR(3)

CHECK(VALUE IS NULL OR VALUE = UPPER(VALUE));

Это замечательно — и мы хотим усилить это правило. Само по себе такое ограничение вызовет исключение, если любое клиентское приложение попытается передать символы в нижнем регистре. С помощью триггера мы можем полностью убрать исключение, исправляя попытки нарушений на месте:

CREATE TRIGGER BA_ATABLE FOR ATABLE

ACTIVE BEFORE INSERT OR UPDATE

BEGIN

NEW.ATYPECODE = UPPER(NEW.ATYPECODE);

END ^

! ! !

ПРИМЕЧАНИЕ. В настоящий момент Firebird поддерживает триггеры только для таблиц и просмотров. Невозможно создать триггер для домена, однако это было бы элегантным улучшением.

. ! .

Значения по умолчанию

В определениях доменов и столбцов вы можете указать значение по умолчанию: DEFAULT. Кажется хорошей идеей устанавливать значение столбца, не допускающего значение NULL В некоторое значение по умолчанию, однако SQL-атрибут DEFAULT на деле оказывается беззубым зверем. Он работает только при двух условиях:

* при использовании операции INSERT;

* если этот столбец не включен во входной список оператора.

Поскольку многие современные интерфейсы приложений автоматически создают оператор INSERT, используя выходные столбцы оператора SELECT В качестве входного

списка, то все столбцы помещаются в этот список. Если само приложение не предоставляет значение по умолчанию, то обычным результатом является передача значения NULL. Когда сервер получает значение NULL для такого столбца, он сохраняет в базе данных NULL. Другие ограничения столбца могут вклиниться сюда и вызвать исключение — особенно ограничение NOT NULL — однако значение по умолчанию для столбца никогда не перекроет и не скорректирует любое значение, полученное от клиентского интерфейса.

Вторая проблема связана, конечно, с тем, что значения по умолчанию никогда не применяются, если используется операция изменения.

Короче говоря, триггеры выполняют гораздо более эффективную работу по поддержанию значений по умолчанию, чем это делают атрибуты значения по умолчанию для столбца. Возьмем для примера столбец, основанный на следующем домене:

CREATE DOMAIN MONEY NUMERIC (18, 0)

NOT NULL DEFAULT 0.00;

Триггер BEFORE INSERT OR UPDATE для любого столбца, использующего домен MONEY, реализует значение по умолчанию:

CREATE TRIGGER BI_ACCOUNT FOR ACCOUNT

ACTIVE BEFORE INSERT OR UPDATE

BEGIN

IF (NEW.BALANCE IS NULL) THEN

NEW.BALANCE = 0.00;

END ^

! ! !

СОВЕТ. Вы можете обеспечить поддержание всех значений по умолчанию для таблицы в едином триггерном модуле (версия 1.5 и выше) или в двух параллельных модулях: один для BEFORE INSERT, а другой для BEFORE UPDATE (версия 1.0.x).

. ! .

Автоматическое заполнение

Триггеры полезны для «автоматического заполнения» контекстной информацией столбцов, созданных для подобных целей. Firebird предоставляет множество контекстных переменных, которые вы можете использовать в операциях такого рода. Вы можете также использовать ваши собственные «флаги», которые вы вычисляете или просто поставляете в виде констант в процессе выполнения триггера.

В следующем примере мы используем триггер AFTER для множества событий с целью автоматического заполнения имени пользователя, даты, времени и идентификатора транзакции для помещения в файл протокола вместе с некоторой информацией о событии. Поскольку регистрируется процесс, то, скорее всего, мы захотим выполнить это в самом конце; присвоим триггеру высокий последовательный номер:

CREATE TRIGGER AA_MEMBER FOR MEMBER

ACTIVE AFTER INSERT OR UPDATE OR DELETE

POSITION 99

DECLARE VARIABLE MEM_ID INTEGER;

DECLARE VARIABLE DML_EVENT CHAR(4);

BEGIN

IF (DELETING) THEN

BEGIN

MEM_ID = OLD.MEMBER_ID;

DML_EVENT = ‘DEL ‘;

END

ELSE

BEGIN

MEM_ID = NEW.MEMBER_ID;

IF (UPDATING) THEN

DML_EVENT = ‘EDIT’;

ELSE

DML_EVENT = ‘NEW ‘;

END

INSERT INTO PROCESS_LOG (

TRANS_ID,

USER_ID,

MEMBER_ID,

DML_EVENT,

TIME_STAMP)

VALUES (

CURRENT_TRANSACTION,

CURRENT_USER,

:MEM_ID,

:DML_EVENT,

CURRENT_TIMESTAMP) ;

END ^

Конечно, вы также можете заполнять ваши новые или редактируемые строки непосредственно в триггере BEFORE.

Изменение других таблиц

В предыдущем примере мы увидели, как триггеры AFTER могут выполнять изменения в других таблицах для автоматизации управления такими задачами, как ведение протокола. Возможности расширить область действия события DML за пределы непосредственного контекста таблицы и строки, «владеющей» данными, имеют некоторые приложения для управления сложными отношениями.

Поддержание обязательного отношения

Обязательное отношение существует, когда две таблицы связаны через зависимость внешнего ключа и должна существовать по меньшей мере одна строка для каждой первичной строки. Поскольку SQL не предоставляет ограничения «обязательности», нужна логика триггера для осуществления правила «минимум один потомок» не только во время создания, но и при удалении зависимых строк.

Следующий пример вкратце описывает один способ использования триггеров для осуществления такого обязательного отношения главная-подчиненная. В нем предполагается, что первичный ключ главной таблице известен в приложении до того, как посылается новая запись.

Во-первых, создадим две таблицы:

CREATE TABLE MASTER (

ID INTEGER NOT NULL PRIMARY KEY,

DATA VARCHAR(10));

COMMIT;

CREATE TABLE DETAIL (

ID INTEGER NOT NULL PRIMARY KEY,

MASTER_ID INTEGER,

/* Столбец внешнего ключа сознательно сделан в виде, допускающем пустое значение */

DATA VARCHAR(10),

TEMP_FK INTEGER,

CONSTRAINT FK_MASTER FOREIGN KEY(MASTER_ID)

REFERENCES MASTER

ON DELETE CASCADE);

COMMIT;

Когда приложение посылает (post) строки главной и подчиненной таблиц, оно вначале будет передавать подчиненные строки со значением NULL в столбце внешнего ключа и со значением первичного ключа главной таблицы в столбце TEMP FK.

Затем нам нужно исключение, которое будет возникать при попытке нарушения правила обязательности и при удалении последней подчиненной строки. Мы также создадим генератор для подчиненной строки.

CREATE EXCEPTION CANNOT_DEL_DETAIL

‘This is the only detail record: it can not be deleted.’;

/* Это единственная подчиненная запись: она не может быть удалена */

CREATE GENERATOR GEN_DETAIL;

COMMIT;

Следующий триггер проверяет подчиненную таблицу после добавления новой версии главной записи. Он может «видеть» подчиненные строки, ранее посланные в той же транзакции, которые имеют значение первичного ключа (NEW.ID) В столбце TEMP FK. В случае изменения, в отличие от добавления, он также может определить подчиненные строки, которыми уже «владеет» главная строка. Любые строки, которые соответствуют условию TEMP_FK, получают значение их внешнего ключа, а TEMP_FK устанавливается в NULL.

Если не найдено строк, соответствующих этому условию, то триггер добавляет «пустую» подчиненную строку.

SET TERM ^;

CREATE TRIGGER AI_MASTER FOR MASTER

ACTIVE AFTER INSERT OR UPDATE POSITION 1

BEGIN

IF (NOT (EXISTS (

SELECT 1 FROM DETAIL WHERE MASTER_ID = NEW.ID

OR TEMP_FK = NEW.ID))) THEN

INSERT INTO DETAIL (MASTER_ID)

VALUES (NEW.ID);

ELSE

IF (NOT (EXISTS (

SELECT 1 FROM DETAIL WHERE MASTER_ID = NEW.ID))) THEN

UPDATE DETAIL SET

MASTER_ID = NEW.ID,

TEMP_FK = NULL

WHERE TEMP_FK = NEW.ID;

END ^

Подчиненная таблица получает автоматически сгенерированный ключ:

CREATE TRIGGER BI_DETAIL FOR DETAIL

ACTIVE BEFORE INSERT AS

BEGIN

IF (NEW.ID IS NULL) THEN

NEW.ID = GEN_ID(GEN_DETAIL, 1);

END ^

Следующий триггер BEFORE DELETE для подчиненной таблицы не позволит удалить строку, если она единственная:

CREATE TRIGGER BD_DETAIL FOR DETAIL

ACTIVE BEFORE DELETE POSITION 0

BEGIN

IF (NOT (EXISTS (

SELECT 1 FROM DETAIL

WHERE MASTER_ID = OLD.MASTER_ID

AND ID <> OLD.ID)))

THEN

EXCEPTION CANNOT_DEL_DETAIL;

END ^

Сейчас у нас ситуация, когда обязательное отношение защищено настолько хорошо, что при попытке удалить главную строку этот триггер не позволит выполнить каскадное удаление. Нам нужно еще два триггера для главной таблицы, расширяющие действия триггеров, созданных системой для каскадного удаления. В триггере BEFORE DELETE для главной таблицы мы заполняем пустым значением внешний ключ подчиненной таблицы и устанавливаем значение столбца TEMP FK. После того как будет

выполнено удаление строки главной таблицы, мы возвращаемся назад и удаляем подчиненную строку.

CREATE TRIGGER BD_MASTER FOR MASTER

ACTIVE BEFORE DELETE

BEGIN

UPDATE DETAIL

SET MASTER_ID = NULL,

TEMP_FK = OLD.ID

WHERE MASTER_ID = OLD.ID;

END ^

/* */

CREATE TRIGGER AD_MASTER FOR MASTER

ACTIVE AFTER DELETE AS

BEGIN

DELETE FROM DETAIL

WHERE TEMP_FK = OLD.ID;

END ^

COMMIT ^

SET TERM; ^

К сожалению, этот пример вряд ли удовлетворит всем требованиям обязательных отношений. Обычно необходимо рассмотреть некоторые другие факторы в терминах требований бизнес-правил и интерфейса программирования. Для логики триггеров редко не появляются такие причины.

Поддержка ссылочной целостности

Формально — или декларативно — ограничения ссылочной целостности должны использоваться везде, где они практически нужны. Проверка, выполняющаяся при поддержке формальных ограничениях ссылочной целостности, осуществляется внутренне триггерами. Если вы хотите расширить действия по ссылочной целостности, вам нужно создать для этого триггеры.

Реализация ссылочной целостности без использования ограничений

Некоторые твердолобые люди годами разрабатывают программы под Firebird и InterBase, избегая декларативной ссылочной целостности, и используют для этого триггеры. Не существует технических причин в любой версии Firebird исключать декларативную ссылочную целостность, если она вам нужна- это работает очень хорошо и не требует многих ресурсов.

Однако декларативная ссылочная целостность требует внешнего ключа, который в свою очередь требует обязательного индекса. В Firebird пока не существует способа поддерживать внешние ключи без обязательного индекса. Существует ситуация, достаточно общая, чтобы обратить на нее внимание, когда индекс для внешнего ключа оказывается весьма плохим с точки зрения производительности в запросах, включающих данную таблицу. Здесь следует исключить формальные ссылочные отношения. Такая ситуация возникает, когда при проектировании появляются таблицы, часто называемые таблицами «соответствия», «системными» или «управляющими».

Таблица соответствия

Таблица соответствия (lookup) или управляющая таблица обычно является статичной таблицей с небольшим количеством строк, которая может быть использована похожим образом в нескольких различных контекстах. Она содержит небольшой первичный ключ и поле описания, коэффициент для вычисления или некоторое правило, к которым нужно обратиться процессу. Примерами являются таблицы налогов, типы счетов, типы транзакций, коды причин и т.д. Процесс нормализации будет нарушен, если системная таблица, связанная с другими таблицами (обычно со многими), будет сохранять ключи соответствия в пользовательской таблице. Поскольку одна строка в таблице соответствия предоставляет информацию для многих строк, строгое соблюдение правил реляционного анализа часто приводит к внешним ключам, помещенным в столбцы ключей соответствия в пользовательских таблицах.

Это полностью допустимый и стандартный способ использования отношений — что мы можем сделать без него? Однако существует тенденция использования небольшого количества значений ключей соответствия в большой динамичной пользовательской таблице. Такие большие таблицы часто содержат немалое количество подобных ключей соответствия в виде внешних ключей, а с ними и множество автоматических нехороших индексов, которые не могут быть удалены. Результатом небольшого количества значений в большом индексе может стать увеличение размера индекса, который становится все менее и менее селективным по мере роста таблицы. По природе индексирования в Firebird понятно, что такие индексы соответствия могут попросту убить эффективность запроса. Обсуждение этой проблемы см. в разд. «Тема оптимизации» главы 18.

Индексы, поддерживающие внешние ключи, являются обязательными и могут быть удалены только при удалении этого ограничения. Кроме того, с удалением такого ограничения вы теряете защиту с автоматическими триггерами ссылочной целостности. Способом разрешения такой дилеммы является написание ваших собственных триггеров ссылочной целостности.

Специальное отношение: пользовательская обработка ссылочной целостности

Этот раздел посвящен специальному виду отношений, системным соответствиям (lookup), которые обычно не поддерживаются в декларативной ссылочной целостности. Используемая здесь терминология соответствует требованиям подобного случая, поскольку установка полностью контролируемой пользователем ссылочной целостности является нецелесообразной для обычных отношений главная-подчиненная. Рис. 31.1 иллюстрирует эту ситуацию. Инициатор запроса, которым может быть любая таблица, имеет ключ соответствия, который указывает на одну, уникально определяемую ключом строку в таблице соответствия. Значение этой строки предоставляется таблице соответствия по запросу.

Рис. 31.1. Отношение-инициатор запроса — таблица соответствия

Для поддержания ссылочной целостности нам нужен триггер, который предоставит набор мер безопасности пользователям таблицы соответствия (инициаторы запроса) так же, как и декларативная ссылочная целостность обеспечивает меры безопасности для защиты зависимостей главная-подчиненная^[124].

* Строка соответствия не может быть удалена, если на нее есть ссылки. Для этого нам нужен триггер BEFORE DELETE К таблице соответствия для проверки такой ситуации и при необходимости выдачи исключения и остановке операции.

* Мы должны обеспечить осуществление правила, чтобы требуемый запросом ключ соответствия соответствовал ключу в таблице. Наше правило может допускать или не допускать для ключа соответствия пустое значение.

* Нам может понадобиться правило, чтобы статичное значение никогда не менялось. В таблице налогов, например, один и тот же код налога (внешний) может быть связан с различными суммами и формулами в разные годы. Вероятно, только главному бухгалтеру будет позволено изменять строку соответствия.

* Триггер BEFORE UPDATE для инициатора запроса потребуется для обработки сложного правила, такого как описано в предыдущем пункте для проверки дат и, возможно, других критериев для осуществления правила и выбора корректного ключа.

Реализация пользовательской ссылочной целостности

Предположим, мы имеем следующие две таблицы:

CREATE TABLE LOOKUP (

UQ_ID SMALLINT NOT NULL UNIQUE,

VALUE1 VARCHAR(30) NOT NULL,

VALUE2 CHAR(2) NOT NULL,

START_DATE DATE,

END_DATE DATE) ;

COMMIT;

/* */

CREATE TABLE REQUESTOR (

ID INTEGER NOT NULL PRIMARY KEY,

LOOKUP_ID SMALLINT,

DATA VARCHAR(20)

TRANSAC_DATE TIMESTAMP NOT NULL) ;

COMMIT;

Теперь мы перейдем к установлению правил существования для двух таблиц. Мы планируем использовать исключения для остановки событий DML, которые нарушают целостность. Следовательно, вначале мы создадим эти исключения:

CREATE EXCEPTION NO_DELETE

‘Can not delete row required by another table’;

/* Нельзя удалять строку, нужную другой таблице */

CREATE EXCEPTION NOT_VALID_LOOKUP

‘Not a valid lookup key’;

/* Неверный ключ соответствия */

CREATE EXCEPTION NO_AUTHORITY

‘You are not authorized to change this data’;

/* Вы не можете изменять эти данные */

COMMIT;

Первый триггер выполняет проверку существования при попытке удалить строку соответствия:

SET TERM ^;

CREATE TRIGGER BD_LOOKUP FOR LOOKUP

ACTIVE BEFORE DELETE

BEGIN

IF (EXISTS(

SELECT LOOKUP_ID FROM REQUESTOR

WHERE LOOKUP_ID = OLD.UQ_ID)) THEN

EXCEPTION NO_DELETE;

END ^

Другая сторона проверки существования: ключ соответствия не может быть назначен, если он отсутствует в таблице соответствия:

CREATE TRIGGER BA_REQUESTOR FOR REQUESTOR

ACTIVE BEFORE INSERT OR UPDATE

BEGIN

IF (NEW.LOOKUP_ID IS NOT NULL

AND NOT EXISTS (

SELECT UQ_ID FROM LOOKUP

WHERE UQ_ID = NEW.LOOKUP_ID)) THEN

EXCEPTION NOT_VALID_LOOKUP;

END ^

Теперь мы можем добавить остальные триггеры для осуществления других нужных нам правил. Например, следующий триггер позволяет выполнять изменения или удаления в таблице соответствия только заданному пользователю:

CREATE TRIGGER BA_LOOKUP FOR LOOKUP

ACTIVE BEFORE UPDATE OR DELETE

BEGIN

IF (CURRENT_USER <> ‘CHIEFACCT’) THEN

EXCEPTION NO_AUTHORITY;

END ^

Этот триггер будет проверять входной код соответствия, чтобы убедиться, что он правилен для периода транзакции, и будет корректировать его при необходимости:

CREATE TRIGGER BA_REQUESTORl FOR REQUESTOR

ACTIVE BEFORE INSERT OR UPDATE POSITION 1

DECLARE VARIABLE LOOKUP_NUM SMALLINT;

DECLARE VARIABLE NEED_CHECK SMALLINT = 0;

BEGIN

IF (INSERTING AND NEW.LOOKUP_ID IS NOT NULL) THEN

NEED_CHECK = 1;

IF (UPDATING) THEN

IF (

(OLD.LOOKUP_ID IS NULL

AND NEW.LOOKUP_ID IS NOT NULL)

OR (OLD.LOOKUP_ID IS NOT NULL

AND NEW.LOOKUP_ID <> OLD.LOOKUP_ID)) THEN

NEED_CHECK = 1;

IF (NEED_CHECK = 1) THEN

BEGIN

SELECT L1.UQ_ID FROM LOOKUP L1

WHERE L1.START_DATE <= CAST(NEW.TRANSAC_DATE AS DATE)

AND L1.END_DATE >= CAST(NEW.TRANSAC_DATE AS DATE)

AND L1.VALUE2 = (SELECT L2.VALUE2 FROM LOOKUP L2

WHERE L2.UQ_ID = NEW.LOOKUP_ID)

INTO :LOOKUP_NUM;

NEW.LOOKUP_ID = LOOKUP_NUM;

END

END ^

COMMIT ^

SET TERM ;^

Изменение строк в той же таблице

Прежде чем решать вопрос об использовании триггера для изменения строк в той же самой таблице, внимательно рассмотрите возможность завершения цикла вложенной деятельности. Если триггер выполняет действие, которое приводит к вызову этого же триггера, или это действие вызывает другой триггер, который выполняет действие, вызывающее данный же триггер, то результатом будет бесконечный цикл. По этой причине важно убедиться, что действия триггера никогда не приведут к вызову триггером самого себя, даже опосредованно.

Если при проектировании базы данных вы подошли к моменту, когда вам нужно написать триггер, который реализует зависимости данных между строками одной и той же таблицы, то, скорее всего, это сигнал о неправильной нормализации таблиц, если только эта зависимость не относится к иерархической структуре. Если фрагмент структуры строки влияет на (или на него влияет) изменение состояния другой строки, то такой сегмент должен быть в результате нормализации перенесен в другую таблицу с внешним ключом для поддержания правила зависимости.

Ссылающиеся на себя таблицы и деревья

Ссылающиеся на себя таблицы, которые реализуют древовидные структуры^[125], являются особым случаем^[126]. Каждая строка в подобной таблице является узлом дерева и может иметь зависимые строки. Любой узел потенциально может иметь две роли: одна- роль родителя для узлов ниже него, а другая — роль потомка узла более высокого уровня. Триггеры, скорее всего, будут нужны для всех событий DML: для модификации поведения ограничений ссылочной целостности и для поддержания мета- таблиц (графов), используемых в некоторых иерархических алгоритмах, делающих доступной запросам геометрию дерева. Триггеры для деревьев всегда должны быть спроектированы с условиями и переходами, которые защищают структуру от бесконечных циклов.

Изменение той же строки

Никогда не пытайтесь использовать оператор SQL для изменения или удаления той же самой строки, с которой оперирует триггер. Например, не рекомендуется использовать следующий вариант:

CREATE TRIGGER 0_30_SILLY FOR ATABLE

BEFORE UPDATE

BEGIN

UPDATE ATABLE SET ACOLUMN — NEW.ACOLUMN

WHERE ID = NEW.ID;

END ^

Всегда используйте переменные NEW для модификаций в той же строке и никогда не пытайтесь удалять ту же строку в триггере.

Изменение триггеров

Firebird 1.0.x предоставляет только один способ изменения триггеров при использовании операторов DDL, a Firebird 1.5 добавляет еще один.

* ALTER TRIGGER изменяет определение существующего модуля триггера, сохраняя его зависимости от других объектов. Он может быть использован с минимальным беспокойством по поводу деактивации триггера.

* CREATE OR ALTER TRIGGER (версия 1.5 и выше) создает модуль триггера, если он не существует, и работает точно так же, как и CREATE TRIGGER. В противном случае применяются правила ALTER, и зависимости сохраняются.

Любая операция завершится с исключением при любой попытке изменений, которая отменяет зависимости.

Синтаксис для изменения триггеров

Синтаксис:

{ALTER TRIGGER ИМЯ} |

{CREATE OR ALTER TRIGGER имя FOR {таблица | просмотр}

[ACTIVE | INACTIVE]

[{BEFORE | AFTER} {DELETE | INSERT | UPDATE}]

[POSITION число]

AS <тело-триггера>;

ALTER TRIGGER

Предложение FOR ИМЯ, применяемое в CREATE TRIGGER, опускается, ALTER TRIGGER не может использоваться для изменения таблицы, с которой ассоциирован триггер.

Изменение только заголовка

Когда вы используете ALTER TRIGGER для изменения только заголовка, оператор требует по меньшей мере одного изменяемого атрибута после имени триггера. Любой атрибут заголовка, опущенный в этом операторе, остается неизменным.

Следующий оператор деактивирует триггер SAVE_SALARY_CHANGE:

ALTER TRIGGER SAVE SALARY CHANGE INACTIVE;

Если изменяется индикатор фазы (BEFORE или AFTER), ТО событие (UPDATE, INSERT или DELETE) также должно быть указано. Например, следующий оператор заново активирует триггер SAVE_SALARY_CHANGE и указывает, что он будет выполняться до изменения, а не после:

ALTER TRIGGER SAVE_SALARY_CHANGE

ACTIVE BEFORE UPDATE;

Изменение тела

Любое изменение тела триггера приводит к тому, что новое определение тела заменяет старое определение. Оператор ALTER TRIGGER не должен содержать никакую информацию заголовка, кроме имени триггера.

Например, следующий оператор изменяет триггер SET CUST NO, который был создан с таким определением:

CREATE TRIGGER SET_CUST_NO FOR CUSTOMER

BEFORE INSERT

BEGIN

IF (NEW.CUST_NO IS NULL) THEN

NEW.CUST_NO = GEN_ID(CUST_NO_GEN, 1);

END^

Мы изменим этот триггер, чтобы он добавлял новую строку в таблицу NEW CUSTOMERS каждый раз, когда новая строка добавляется в таблицу CUSTOMER:

SET TERM ^;

ALTER TRIGGER SET_CUST_NO

BEFORE INSERT AS

BEGIN

IF (NEW.CUST_NO IS NULL) THEN

NEW.CUST_NO = GEN_ID(CUST_NO_GEN, 1);

INSERT INTO NEW_CUSTOMERS(NEW.CUST_NO, CURRENT_DATE) END ^

SET TERM ;^

CREATE OR ALTER TRIGGER

В версии 1.5 этот новый синтаксис создает триггер, если триггер с указанным именем не найден, или изменяет триггер с этим именем. Просто отредактируйте исходный оператор CREATE нужным образом, добавив ключевые слова OR ALTER.

Ошибка «объект находится в использовании»

Как и в случае с хранимыми процедурами, подтверждение изменений вызовет печально известную ошибку «объект находится в использовании» (Object in use), если в настоящий момент какой-нибудь пользователь использует триггер или какой-либо объект, зависящий от него. В любом случае новая версия триггера не станет немедленно доступной в Суперсервере, если старая версия все еще находится в кэше. Все пользователи должны отключиться от базы данных, а когда они вновь подключатся, то смогут видеть новую версию.

В Классическом сервере новая версия будет доступна следующему клиенту, который соединится с базой данных.

Inactive/Active

В версии 1.5 и более поздних выполнение ALTER TRIGGER … INACTIVE | ACTIVE обычно не приводит к ошибке «объект находится в использовании», если только существующая транзакция не заблокировала таблицу. Такое изменение не влияет на транзакции, которые уже используют эту таблицу. Причем данное изменение будет видимым следующей транзакции, которая запрашивает изменение состояния таблицы.

Удаление триггеров

В процессе проектирования базы данных и разработки приложений триггер может перестать быть полезным. Для удаления триггера соединитесь с базой данных как его владелец или пользователь SYSDBA и используйте оператор DROP TRIGGER.

Его синтаксис:

DROP TRIGGER ИМЯ;

Имя триггера должно быть именем существующего триггера. Следующий пример удаляет триггер SET_CUST_NO:

DROP TRIGGER SET CUST NO;

! ! !

ПРИМЕЧАНИЕ. Чтобы временно сделать триггер недоступным, используйте ALTER TRIGGER имя INACTIVE.

. ! .

Пора дальше

Последняя глава этой части добавляет сахарную глазурь в наш торт для разработчиков базы данных. Firebird имеет две особенности PSQL: обработка пользовательских исключений и события. С помощью исключений вы имеете весьма детальный контроль над перехватом и обработкой сотен внутренне определенных условий ошибок и множеством ваших собственных исключений. С помощью событий вы можете реализовать механизм обратных вызовов, чтобы проинформировать приложения удаленных клиентов о подтвержденных изменениях, выполненных другими клиентами.

ГЛАВА 32. Обработка ошибок и события.

В этой главе мы рассмотрим, как при выполнении модулей PSQL — триггеров и процедур — можно перехватывать и обрабатывать ошибки в выполняемом коде.

Стандартным поведением модулей PSQL при появлении исключений является остановка выполнения, отмена всей работы, выполненной с начального оператора BEGIN, переход на конечный оператор END и возврат управления клиенту с передачей одного или более сообщений об ошибке. Если этим модулем является триггер, исключение отменит работу всех предыдущих триггеров и предотвратит посылку запрашиваемых изменений DML.

Типы исключений

Может появиться три типа исключений.

* Ошибки SQL — т. е. сообщения SQL, имеющие отрицательное значение SQLCODE.

* Внутренние ошибки Firebird, которые имеют отношение к конкурирующему взаимодействию, данным, метаданным и условиям окружения. У них есть девяти- символьный код ошибки, обычно начинающийся с 3355, который уникально идентифицирует код GDSCODE. Большинство кодов GDSCODE попадают в обобщающие группы кодов SQLCODE, и при возникновении исключения вы обычно получаете и SQLCODE, и GDSCODE.

* Пользовательские исключения, которые вы объявляете как постоянные объекты базы данных и «вызываете» в коде, когда определяется специфическое условие.

Что такое исключение?

Исключение — это просто сообщение, которое генерируется, когда появляется ошибка.

Все предварительно определенные исключения — SQLCODE и GDSCODE — имеют ассоциированные с ними тексты сообщений. Сообщения по умолчанию на английском языке, но могут использоваться и другие языки. Существует небольшое количество версий сообщений на других языках (включая латинский!), другие или «находятся в работе», или «ожидают желающих поработать»^[127].

В Firebird существует синтаксис DDL для создания пользовательских исключений с текстами сообщений до 78 символов. В Firebird 1.5 вы можете расширить ваши пользовательские исключения во время выполнения, заменить текст сообщения, посылаемого по сети, в зависимости от контекста.

Создание исключения

Создание исключения является одним из самых простых элементов DDL. Синтаксис:

CREATE EXCEPTION имя-исключения <сообщение>;

Имя-исключения- обычный идентификатор Firebird до 31 символа длиной. Оно должно быть уникальным среди идентификаторов исключений, а в диалекте 3 может быть заключено в кавычки. Тогда имя будет чувствительным к регистру.

<сообщение> — заключенная в апострофы строка текста в наборе символов NONE. Из-за ограничения размера текст должен быть лаконичным. Например:

CREATE EXCEPTION NO_DOGS ‘NO dogs allowed!’; COMMIT;

Оператор CREATE EXCEPTION должен быть подтвержден, как и любой другой оператор DDL.

Изменение и удаление исключения

Как пользователь SYSDBA или владелец исключения, которое используется в хранимых процедурах, вы можете изменять или удалять его в любое время. Если оно используется в триггере, вы можете его только изменять и изменять только текст сообщения. Не хранится никаких зависимостей для исключений, используемых в хранимых процедурах. Это создает проблему в случае, когда вы удаляете исключение и забываете убрать его из хранимых процедур — будет неловко получить исключение по причине отсутствия исключения!

Для удаления нашего исключения NO_DOGS введите:

DROP EXCEPTION NO_DOGS;

Для его изменения:

ALTER EXCEPTION NO_DOGS ‘NO dogs allowed except Irish Wolfhounds!’;

! ! !

СОВЕТ. При конструировании скриптов схемы сгруппируйте вместе все ваши операторы CREATE EXCEPTION, чтобы их было проще отыскивать в процессе разработки и модификации, а также с целью документирования. Разработчики часто используют короткие префиксы или какую-нибудь систему именования исключений в соответствии с категориями пользовательских исключений.

. ! .

Исключения в действии

Внутренне определенные исключения вызываются ядром сервера в ответ на соответствующие ошибки, которые требуют прекращения выполнения. Они охватывают большое количество условий, включая каждый вид нарушения ограничений, арифметические и строковые переполнения, ссылки на отсутствующие объекты, разрушение данных и т.д. Исключения SQLCODE и GDSCODE являются теми же самыми исключениями, что и исключения, используемые при появлении ошибок в процессе выполнения операций динамического SQL. Они описаны в приложении 10.

Пользовательские исключения, доступные только в модулях PSQL, не должны дублировать работу внутренне определенных исключений. Определяйте ваши исключения для использования там, где вы хотите в вашем коде выявлять ошибочные ситуации, которые нарушают ваши бизнес-правила. Три вида исключений изображены на рис. 32.1.

У нас был в главе 30 пример, в котором пользовательское исключение применялось в триггере для прекращения события, продолжение которого нарушило бы бизнес-правило. В этом случае хранимая процедура позаботится о том, чтобы убрать зависимости из организационной структуры при удалении служащего. Это было объявлено следующим образом:

CREATE EXCEPTION REASSIGN_SALES

‘Reassign the sales records before deleting this employee.’ ^

/* Переназначьте записи продаж перед удалением этого служащего */

COMMIT ^

Рис. 32.1. Стандартная реакция PSQL на исключения

В том месте, где используется это исключение, процедура проверяет, является ли данный служащий участником продаж в каком-либо документе продаж. Если да, то используется пользовательское исключение для завершения процедуры. Конечно, если возникает исключение, то все другие действия, выполненные в процедуре, отменяются.

BEGIN

IE (EXISTS (SELECT PO_NUMBER FROM SALES

WHERE SALES_REP = : emporium) ) THEN

EXCEPTION reassign_sales;

! ! !

ПРИМЕЧАНИЕ. В хранимых процедурах выбора выходные строки, которые уже были получены клиентом в предыдущих циклах FOR SELECT … DO … SUSPEND, остаются доступными для клиента. О механизме, работающем в этом случае, см. далее разд. «Оператор WHERE».

. ! .

Существуют случаи, когда возможно использовать пользовательское исключение как способ вмешательства в возникшую проблему и позволить процедуре продолжать выполнение. Вы можете перехватить исключение и написать код для его обработки прямо в этой процедуре. В следующем разделе рассматривается, каким образом эта техника перехвата и исправления может быть использована при исключении REASSIGN_SALES.

Обработка исключений

Код PSQL может перехватывать ошибки при их появлении и затем их обрабатывать в подпрограмме обработки исключений. Если исключение будет обработано в вашем коде- вы обеспечите исправление или обход ошибки и позволите продолжить выполнение, — то клиенту не возвращается никакого сообщения об исключении. Рис. 32.2 иллюстрирует логику перехвата и обработки ошибок.

Как и раньше, исключение приводит к прекращению выполнения в блоке. Вместо того чтобы передать выполнение на конечный оператор END, теперь процедура отыскивает уровни во вложенных блоках, начиная с блока, где была выявлена ошибка, и переходит на внешние блоки, чтобы найти код обработчика, который «знает» о таком исключении. Она отыскивает первый оператор WHEN, который может обработать эту ошибку.

Оператор WHEN

Оператор WHEN имеет следующую форму:

WHEN <исключение> DO <составной-оператор>

Здесь исключение может быть одним из следующих:

<имя-исключения> | GDSCODE код | SQLCODE код ANY

<составной-оператор> может быть одним оператором или множеством обычных операторов PSQL, заключенным в блок BEGIN … END.

Рис. 32.2. Логика перехвата и обработки ошибок

Область видимости типов исключений

Принцип типов исключений, показанный в структурах синтаксиса, представляет объем области видимости.

Пользовательское исключение может соответствовать любому выбранному вами условию, включая правила, которые вы, может быть, не в состоянии реализовать с помощью выражений в ограничениях. Операторы WHEN и код обработчика пользовательских исключений лучше всего поместить в тот же блок, где может появиться ошибка.

Следующим по глубине является GDSCODE. В версии 1.0.x это контекстная переменная, в которой процедура может только получить код и сравнить его с кодом, заданным в предикате WHEN:

WHEN GDSCODE foreign_key DO

BEGIN

. . .

END

Начиная с версии 1.5, GDSCODE является «полнофункциональной» контекстной переменной. При ее чтении внутри блока, где возникло исключение, вы можете сохранить этот код в записи протокола.

! ! !

СОВЕТ. Все коды GDSCODE имеют символические константы, которые являются более или менее понятными для людей, знающих английский язык. Именно эти символические константы вы должны использовать в операторах WHEN GDSCODE, а не числовые коды. Если вы посмотрите заголовочный файл iberror.h в вашем каталоге /include, вы увидите, что определение символических констант имеют префикс isc_. Этот префикс должен быть опущен в операторах WHEN GDSCODE.

. ! .

Некоторые ошибки, выявленные в GDSCODE, могут быть исправлены внутри области действия блока, где они появились. Если это так, то оператор WHEN для обработки таких ошибок должен находиться здесь, иначе он должен быть помещен во внешний цикл для обработки там ошибок.

Код SQLCODE является довольно общим, он не всегда соответствует типу ошибки. Операции SQL передают SQLCODE 0 при успешном завершении и SQLCODE 100 при достижении конца файла. Диапазон неиспользуемых «сегментов» находится между 1 и 99 для предупреждающих и информационных сообщений. Диапазон ошибок SQLERROR — отрицательные числа, которые больше -1000. Такие коды ошибок SQLERROR в SQLCODE обычно являются группировкой на более высоком уровне нескольких кодов GDSCODE.

Как и GDSCODE, SQLCODE допускает только программное чтение в версии 1.0.x, но становится настоящей контекстной переменной в версии 1.5 и более поздних. Вы можете поместить это значение в протокол.

! ! !

ПРИМЕЧАНИЕ. Вы можете использовать либо GDSCODE, либо SQLCODE. Вы получите код для одного и NULL для другого.

. ! .

Коды SQLCODE менее детализированы и в большинстве случаев менее всего подходят для условий, которые могут быть исправлены внутри модуля. Посмотрите коды в приложении 10, обратите внимание, что один код SQLCODE чаще всего группирует несколько кодов GDSCODE. Обычно они более полезны во внешнем блоке модуля.

Ключевое слово ANY- это «оставшиеся исключения». Оно означает перехват любого определенного внутренне исключения, которое не было обработано. В версии 1.5, наряду с возможностью чтения GDSCODE или SQLCODE (в рамках области действия), у ANY

есть лучшая возможность создания обработчика по умолчанию, чем в предыдущих версиях.

Размещение блоков WHEN

Всегда помещайте ваши блоки WHEN непосредственно перед оператором END, закрывающим тот блок, исключения которого вы хотите обрабатывать. Не помещайте никакие другие операторы — даже SUSPEND или EXIT — между концом ваших обработчиков и завершающим оператором END. Вернитесь к рис. 32.2, где описан этот поток.

! ! !

СОВЕТ. Если вы хотите использовать оператор EXIT непосредственно перед финальным оператором END вашего модуля с целью документирования, то это нормально. В этом месте оператор EXIT не может повлиять на поток выполнения.

. ! .

Когда процедура встречает ошибку в цикле курсора процедуры выбора, отменяются все операторы, начиная с последнего и до предыдущего SUSPEND. Эта отмена не влияет на строки, уже выведенные предыдущими вызовами SUSPEND; они остаются доступными для клиента.

Оператор SUSPEND не должен использоваться в выполняемых процедурах. Пусть логика вашего выполнения определяет, когда блоки завершаются и когда ошибки должны возвращаться в виде исключений.

Вложенные исключения в качестве точек сохранения

Вложенная архитектура блоков выполнения модулей PSQL означает, конечно, что PSQL поддерживает «вложенные» транзакции. Деятельность каждого модуля PSQL выполняется в контексте той транзакции, в которой он был вызван. Стандартный поток выполнения гарантирует, что работа либо завершится как единое целое, либо вся будет отменена. В случае хранимых процедур исключение приводит к отмене всей работы, выполненной во время вызова. В случае триггеров исключение приводит к отмене DML и всех уже выполненных действий, связанных с этой операцией.

Обработка исключений предоставляет средства для разбиения выполнения на этапы, которые могут быть отменены до определенной точки без необходимости отмены всей работы модуля. Уровень отмены определяется в точке появления ошибки и ближайшего предложения обработчика WHEN. Такая «точка сохранения» — эквивалент именованной точки сохранения в управляемой клиентом транзакции — создается в коде блока, в котором выполняется код обработчика WHEN.

Обработка исключения REASSIGN_SALES

Теперь вернемся к нашей процедуре DELETE_EMPLOYEE. В главе 30, когда эта процедура сталкивалась с ситуацией, где удаляемый служащий имеет заказы в картотеке, она выдавала пользовательское исключение REASSIGN_SALES и просто прекращала работу, отменяла выполненные действия и посылала сообщение исключения работающему с ней человеку.

Однако мы можем заставить процедуру обработать эту ситуацию и позволить процедуре завершиться. Например, обработчик может обнулить ключ SALES_REP и послать сообщение другой процедуре, которая создаст записи в таблице протокола для каждой соответствующей записи продаж.

Мы начинаем с создания таблицы протокола:

SET TERM ^;

CREATE TABLE EMPLOYEE_LOG (

EMP_NO SMALLINT,

TABLE_AFFECTED CHAR(31),

FIELD_AFFECTED CHAR(31),

FIELD_VALUE VARCHAR(20),

USER_NAME VARCHAR(31),

DATESTAMP TIMESTAMP) ^

COMMIT ^

Затем нам нужно создать процедуру, которая будет выполнять протоколирование. Она будет достаточно общей, потому что мы полагаем, что подобная процедура протоколирования может понадобиться и для других задач в этой системе:

CREATE PROCEDURE LOG_ACTION (

EMP_NO SMALLINT,

TABLE_AFFECTED CHAR(31),

FIELD_AFFECTED

CHAR(31),

FIELD_VALUE VARCHAR (20))

BEGIN

INSERT INTO EMPLOYEE_LOG

VALUES (:EMP_NO, :TABLE_AFFECTED, :FIELD_AFFECTED,

:FIELD_VALUE, CURRENT_USER, CURRENT_TIMESTAMP) ;

END ^

Последнее, что нужно сделать, — это добавить код обработки исключения в нашу процедуру DELETE_EMPLOYEE:

RECREATE PROCEDURE DELETE_EMPLOYEE (

:emp_num INTEGER)

DECLARE VARIABLE PO_NUMBER CHAR(8);

BEGIN

IF (EXISTS (SELECT PO_NUMBER FROM SALES

WHERE SALES_REP = : emporium)) THEN

EXCEPTION reassign_sales;

В этом месте, если появится исключение, последующие операторы не будут выполняться, и управление будет передано на первый оператор WHEN, который может обрабатывать это исключение.

UPDATE department …

SET …

. . .

DELETE FROM employee

WHERE emp_no = :emp_num;

Вот блок обработчика. Первым делом он в цикле просматривает таблицу SALES и устанавливает SALES_REP в NULL во всех строках, где появляется код нашего удаляемого служащего. В каждой итерации этого цикла он вызывает процедуру протоколирования, передавая ей код служащего вместе с информацией о записи SALES:

WHEN EXCEPTION REASSIGN_SALES DO

BEGIN

FOR SELECT PO_NUMBER FROM SALES

WHERE SALES_REP = :emp_num

INTO :PO_NUMBER

AS CURSOR С

BEGIN

UPDATE SALES SET SALES_REP = NULL

WHERE CURRENT OF C;

EXECUTE PROCEDURE LOG_ACTION (

emp_num, ‘ SALES ‘, ‘ POJSIUMBER’, : PO_NUMBER) ;

END

После завершения цикла главная процедура еще раз вызывает саму себя для завершения обработки, которая была пропущена по причине исключения:

EXECUTE PROCEDURE DELETE?EMPLOYEEl (:emp_num) ;

END

END^

COMMIT ^

Протокол ошибок

Если для вас важно сохранять протокол ошибок, помните, что исключения, возникающие у клиента, приводят к отмене всей работы, выполненной в модуле. Если вы ведете протокол в таблице базы данных, то записи протокола исчезнут вместе с другой отмененной работой. В случаях, когда обработчики исправят или «проглотят» каждую ошибку, внутренняя таблица будет работать просто прекрасно.

Если вам нужен протокол, который будет сохраняться и после необработанного исключения, используйте внешнюю таблицу. Подробности см. в разд. «Использование внешних файлов в качестве таблиц» главы 16.

! ! !

СОВЕТ. В конце этой главы описано применение подобной техники в процедуре, которая добавляет строки во внешнюю таблицу, хотя последняя не является таблицей протоколирования ошибок.

. ! .

SQLCODE и GDSCODE

В версии 1.5 и выше вы можете перехватить числовой код ошибки, который передается внутренне определенному исключению в контекстной переменной SQLCODE или GDSCODE. Это предоставляет весьма компактный способ протоколирования текущего исключения в виде фрагмента вашей подпрограммы обработки исключений.

Внутренне определенные исключения имеют и SQLCODE, и GDSCODE. Ваш код может обратиться только к одному коду, другой будет недоступен.

! ! !

ПРИМЕЧАНИЕ. Каждый раз, когда вы попытаетесь обратиться к этим кодам вне блока обработчика, вы получите ноль.

. ! .

Следующая структура блока кода завершается группой обработчиков исключений. Первые два обрабатывают ошибки SQLCODE в виде пользовательских исключений. Эти пользовательские исключения могут быть обработаны во внешнем блоке или их назначением может быть аварийное завершение процедуры и возврат клиенту полезного сообщения.

Если не появилось ни одного из предусмотренных исключений, а было некоторое другое, то его перехватит оператор WHEN ANY. Его обработчик вызывает хранимую процедуру для вывода записи протокола, передавая код SQLCODE вместе с другими входными аргументами, полученными из контекста блока:

BEGIN

. . .

WHEN SQLCODE -802 DO

EXCEPTION E_EXCEPTION_1;

WHEN SQLCODE -803 DO

EXCEPTION E_EXCEPTION_2;

WHEN ANY DO

EXECUTE PROCEDURE P_ANY_EXCEPTION (SQLCODE, другие входные данные …);

END

Повторный вызов исключения

Предположим, вам нужно перехватить и внести во внешнюю таблицу протокола непредвиденную ошибку, перед тем как позволить исключению выполнить свою работу и завершить процедуру или триггер. Начиная с версии 1.5, можно повторно вызвать исключение — вы можете выполнить некоторую обработку исключения и завершить обработчик оператором EXCEPTION для возбуждения исключения и передачи управления на конечный END. Выполнение останавливается, и управление передается клиенту с кодом или именем исключения и подходящим сообщением в массиве состояния ошибки.

В вашем обработчике вы выбираете SQLCODE или GDSCODE и некоторые другие контекстные переменные, записываете запись в протокол, а затем заново вызываете исключение:

BEGIN

. . .

WHEN ANY DO

BEGIN

EXECUTE PROCEDURE P_ANY_EXCEPTION (SQLCODE, другие входные данные …);

EXCEPTION; END

END ^

Исключения в триггерах

Пользовательские исключения в триггерах способны поддерживать бизнес-правила. В примере базы данных EMPLOYEE есть правило, по которому покупатели, которым отказано в доверии, отмечаются в столбце ON_HOLD, который ограничен значениями NULL или «*». Когда добавляется запись в SALES или изменяется существующая запись с неотправленным товаром для такого покупателя, то такой заказ отклоняется, если флаг ON_HOLD не имеет значения NULL. Другое правило гласит, что заказ, который уже был отправлен, не может изменяться.

При добавлении или изменении записей заказов мы можем написать триггеры BEFORE, которые при нарушении этих правил выдают исключения и блокируют операцию.

Для любой версии Firebird мы можем написать два триггера для осуществления этих правил: BEFORE INSERT и BEFORE UPDATE.

Создадим исключения для двух условий:

CREATE EXECPTION E_CANT_ACCEPT

‘Operation refused. REASON: Customer is on hold.’ ^

/* Операция отклоняется. Причина: деятельность покупателя приостановлена */

CREATE EXCEPTION E_CANT_EXTEND

‘Operation refused. REASON: Order already shipped.’ ^

/* Операция отклоняется. Причина: заказ уже отправлен */

COMMIT ^

Триггеры для версии 1.0.x:

CREATE TRIGGER BI_SALES0 FOR SALES

ACTIVE BEFORE INSERT POSITION 0 AS

BEGIN

IF (EXISTS (SELECT 1 FROM CUSTOMER

WHERE CUST_NO = NEW.CUST_NO

AND ON_HOLD IS NOT NULL)) THEN

EXCEPTION E_CANT_ACCEPT;

END ^

/* */

CREATE TRIGGER BU_SALES0 FOR SALES

ACTIVE BEFORE UPDATE POSITION 0 AS

BEGIN

IF (OLD.ORDER_STATOS = ‘shipped’) THEN

EXCEPTION E_CANT_EXTEND; ELSE

IF (EXISTS (SELECT 1 FROM CUSTOMER

WHERE CUST_NO = NEW.CUST_NO

AND ON_HOLD IS NOT NULL) ) THEN

EXCEPTION E_CANT_ACCEPT;

END ^

Сообщения исключений во время выполнения

Некоторые улучшения версии 1.5 по обработке сообщений исключений обеспечивают больше возможностей написания обработчиков исключений. Статическое сообщение исключения, определенное в CREATE EXCEPTION, во время выполнения может быть заменено на другой текст, обеспечивающий лучший контекст для пользователя, более точно идентифицирующий проблемные данные.

В следующем примере мы используем возможности версии 1.5 по реализации тех же самых правил, что и в двух триггерах предыдущего примера. На этот раз мы поместим эти правила в один триггер и используем сообщения времени выполнения.

Вот исключение:

CREATE EXCEPTION E_REFUSE_ORDER ‘Operation refused. ‘ ^

/* Операция отвергнута */

А вот триггер:

CREATE TRIGGER BA_SALES0 FOR SALES

ACTIVE BEFORE INSERT OR UPDATE POSITION 0 AS

DECLARE VARIABLE ORDER_STATE SMALLINT = 0;

BEGIN

IF (UPDATING AND OLD.ORDER_STATUS = ‘shipped’) THEN

ORDER_STATE = 1;

IF (

(EXISTS (SELECT ON_HOLD FROM CUSTOMER

WHERE CUST_NO = NEW.CUST_NO

AND ON_HOLD IS NOT NULL)

AND (INSERTING OR ORDER_STATE = 0)) THEN

ORDER_STATE = 2;

IF (ORDER_STATE = 1) THEN

EXCEPTION E_REFUSE_ORDER ‘Order ‘ || NEW.PO_NUMBER || ‘ already shipped.’;

/* EXCEPTION E_REFUSE_ORDER ‘Заказ ‘ || NEW.PO_NUMBER || ‘ уже отправлен’ */

ELSE

IF (ORDER_STATE = 2) THEN

EXCEPTION E_REFUSE_ORDER

‘Order ‘|| NEW.PO_NUMBER ||’. Customer ‘ || NEW.CUST_NO || ‘ is on hold.’;

/* ‘Заказ ‘|| NEW.PO_NUMBER ||’. Покупатель ‘ || NEW.CUST_NO || ‘ заблокирован’; */

END ^

В массиве состояния ошибки клиент получит имя исключения вместе с сообщением времени выполнения.

Список кодов ошибок

Приложение 10 содержит списки внутренне определенных исключений, включая коды SQLCODE, GDSCODE, символы для GDSCODE и сообщения на английском языке, соответствующие текущему состоянию релиза Firebird 1.5.0.

При создании двоичного кода Firebird сообщения на английском языке выбираются из внутренней базы данных. Коды SQLCODE сохраняются, но GDSCODE вычисляются на лету. Файл firebird.msg в вашем корневом каталоге Firebird создан в виде двоичного дерева, к которому обращаются клиент и сервер при работе сервера.

Написание вашего собственного списка кодов ошибок

Ради любопытства вы можете легко получить версию gbak для базы данных (с именем gbak.msg) из репозитория CVS проекта Firebird. Войдите на http:// sourceforge.net/projects/firebird и идите по ссылке CVS Browser, пока не доберетесь до ветви с именем ,/firebird/firebird2/src/msgs/. В нижней части дисплея щелкните по стрелке выпадающего списка для поиска интересующей вас ветви. Оттуда вы сможете получить файл.

Следующая хранимая процедура сгенерировала список для приложения 10. Она выводит список во внешнюю таблицу, но вы можете модифицировать эту процедуру подходящим для вас образом.

SET TERM ^;

/* Выходной файл */

CREATE TABLE ERRORCODES

EXTERNAL FILE

‘С:Program FilesFirebirdFirebird_1_5MyData27 94app10.txt’

(Listltem CHAR(169))^

COMMIT^

/* При необходимости уберите комментарии в следующей секции и объявите функцию ASCII_CHAR() для получения символов возврата каретки и перевода строки */

/* DECLARE EXTERNAL FUNCTION ascii_char

INTEGER

RETURNS CSTRING(1) FREE_IT

ENTRY_POINT ‘IB_UDF_ascii_char’ MODULE_NAME ‘ib_udf’^

COMMIT^

/* Под конец сама хранимая процедура, создающая текстовый файл, эквивалентный приложению 10 данной книги*/

CREATE PROCEDURE OUTPUT ERRCODES

DECLARE VARIABLE SQC SMALLINT;

DECLARE VARIABLE NUM SMALLINT;

DECLARE VARIABLE FAC SMALLINT;

DECLARE VARIABLE SYM VARCHAR(32);

DECLARE VARIABLE TXTVARCHAR(118) ;

DECLARE VARIABLE GDC CHAR(9) CHARACTER SET OCTETS

DECLARE VARIABLE BASEO INTEGER = 335544320;

DECLARE VARIABLE CALCNUM INTEGER;

DECLARE VARIABLE EOL CHAR(2) ;

BEGIN

EOL = ASCII_CHAR(13) || ASCII_CHAR(10);

/* последовательность конца строки */

FOR SELECT

S.SQL_CODE,

S.NUMBER,

S.FAC_CODE,

S. GDS_SYMBOL,

M.TEXT

FROM SYSTEM_ERRORS S

JOIN MESSAGES M

M.FAC_CODE = S.FAC_CODE

AND M.NUMBER = S.NUMBER

AND M.SYMBOL = S.GDS_SYMBOL

/* Устранение некоторых нежелательных/ненужных кодов */

WHERE M.TEXTNOT CONTAINING ‘journal’

AND M.TEXTNOT CONTAINING ‘dump’

AND s.GDS_SYMBOL NOT CONTAINING ‘license’

AND S.GDS_SYMBOL NOT CONTAINING ‘wal_’

AND S. GDS_SYMBOLIS NOT NOLL

AND S.SQL_CODE < 102

ORDER BY1 DESC, 2

INTO :SQC, :NUM, :FAC, :SYM, :TXT

BEGIN

/* Тексты сообщений в нижнем регистре, следовательно, мы выполним небольшой трюк для перевода в верхний регистр первой буквы */

IF (TXT IS NULL) THEN

TXT = ‘(Message unknown)’;

ELSE

TXT = UPPER(SUBSTRING(TXT FROM 1 FOR 1)) ||

SUBSTRING(TXT FROM 2);

/* Разработанные значения кодов (FAC_CODE) и чисел NUMBER используются для генерации чисел GDSCODE. Очень просто получить их из последних таблиц SYSTEM_ERRORS и MESSAGES */

IF (FAC IS NOT NULL AND NUM IS NOT NULL) THEN

/* Нам не нужны наполовину приготовленные коды ошибок! */

BEGIN

CALCNUM = BASE0 + (FAC * 65535);

CALCNUM = CALCNUM + NUM + FAC;

GDC = CAST(CALCNUM AS CHAR(9));

INSERT INTO ERRORCODES

VALUES(

/* все переменные поступают в одной строке */

:SQC || ‘ | ‘ || :GDC | | ‘ | ‘ || :SYM | | ‘ |’ | | :TXT || :EOL) ;

END

END ^

COMMIT^

EXECUTE PROCEDURE OUTPUT_ERRCODES ^

COMMIT ^

SET TERM ; ^

/* Текстовый файл теперь готов к обработке текстовым процессором для небольшой корректировки, чтобы избавиться от лишних пробелов, созданных в правой части выходной строки. Быстрый поиск и замена заменят все разделители ‘|’ на ASCII 9 (tab), потому что это было требованием к табуляции для печати. */

События

События Firebird предоставляют механизм сигнализации, с помощью которого хранимые процедуры и триггеры могут передавать сообщения клиентским приложениям, когда другие приложения подтверждают изменения данных. Клиентские приложения устанавливаются в режим «прослушивания» конкретных событий через интерфейс сервер-клиент без системных затрат на опрос наличия изменений.

Клиентские подсистемы, которые запрашивают у сервера новости об изменениях состояния базы данных, не являются редкостью в мире реляционных подсистем баз данных. Однако модель сообщения о событиях в Firebird не расходует ресурсов сети или процессора при опросе. Это является подсистемой сервера, которая поддерживается сервером и на сервере. Клиент «регистрирует интерес» в событии и сигнализирует, что он ждет этого события.

Когда транзакция подтверждается, сообщения обо всех произошедших событиях передаются всем ожидающим их клиентским приложениям. После этого клиентское приложение может отреагировать на это событие любым образом.

Использование сообщений о событиях

Система сообщений о событиях в Firebird может соответствовать большому количеству требований приложения, которое вызывает эти средства для быстрого реагирования на изменения состояния базы данных, выполненные другими пользователями базы данных. Такие техники могут быть использованы в комбинации со средствами удаленной связи, процессом управления, технологиями планирования и передачи сообщений для автоматизации критичных по времени потоков реагирования.

Эти возможности безграничны в терминах масштаба и приложения. Некоторыми примерами являются:

* сервисы фоновой репликации данных запрашивают новый элемент;

* приложение продажи билетов использует эту схему в качестве сигнала для обновления открытых наборов данных в других офисах, когда происходит изменение выделенных мест или расписания;

* приложение инвентаризации выдает отделу закупок сообщение «запас на исходе», когда количество элементов инвентаризации находится ниже минимально допустимого уровня запасов;

* розничные магазины информируются о загрузке нового прайс-листа;

* устройство слежения за механическим процессом сигнализирует о низком уровне запасов сырья.

Элементы механизма

Инициаторами событий являются операции изменения состояния базы данных — успешно выполненные операции INSERT, UPDATE и DELETE. Сигнализация о событии выполняется в триггерах или хранимых процедурах с помощью оператора PSQL

POST_EVENT.

Однако POST EVENT является только одним элементом этого механизма- изолированно он ничего не делает. Это просто посылка сигнала слушающим приложениям. Он не несет никакой информации, о каком событии базы данных он сигнализирует; задачей приложения является обеспечение собственного контекста для каждого события.

Сам механизм событий состоит из нескольких взаимодействий между серверной стороной и приложением.

Элементы на стороне сервера

Элементами на стороне сервера являются:

* один или более триггеров или хранимых процедур, которые выдают оператор

POST_EVENT;

* внутренняя таблица событий — адресат вызовов POST_EVENT — содержит список направленных ей событий процедурами и триггерами во время работы транзакций, при которых возникли события;

* подсистема управления внутренними событиями, которая поддерживает список прослушивающих и ожидающих приложений и работает как «полицейский- регулировщик» для направления соответствующих событий прослушивающим приложениям.

Элементы приложения

На стороне приложения этому механизму нужно:

* приложение, которое способно зарегистрировать свой интерес в событиях;

* другие приложения, которые выполняют те операции DML, которые прослушивает заинтересованное приложение.

Естественно, прослушивающему приложению также необходим механизм реагирования на события.

Элементы интерфейса

При пересылке событий от сервера клиенту используется пара портов, отличная от порта, используемого в главном канале клиент-сервер (обычно порт 3050). Сервер и клиентская библиотека находят произвольную пару портов для использования в качестве трафика событий.

Элементом программного обеспечения является клиентская подпрограмма, называемая функцией обратного вызова события. Это код на клиенте, который вызывается сервером для информирования клиента о событиях, как только подтвердится транзакция, в рамках которой было отправлено ожидаемое событие. Для встроенных приложений предкомпилятор gpre генерирует код для таких функций обратного вызова. Для динамических приложений, которые хотят выполнять прослушивание синхронно (см. следующий раздел), как это делают приложения ESQL, функция обратного вызова содержится в клиентской библиотеке. Динамические приложения могут — и обычно так и делают — прослушивать асинхронно (см. разд. «Асинхронная сигнализация» и «Асинхронное прослушивание»). Для этого они должны предоставить пользовательскую функцию обратного вызова, называемую асинхронным перехватчиком (Asynchronous Trap, AST).

! ! !

СОВЕТ. Если ваша стратегия межсетевой защиты не позволяет приложениям выбирать произвольный порт, Firebird версии 1.5 и выше позволяет специально сконфигурировать такой вспомогательный порт — используйте параметр RemoteAuxPort В firebird.conf.

. ! .

Синхронное прослушивание

На рис. 32.3 показана модель событий, которая реализована в языке ESQL для встроенных приложений с помощью операторов EVENT INIT и EVENT WAIT. Динамический SQL не имеет эквивалентных операторов SQL. Для приложений динамического SQL та же синхронная модель событий реализована в API с помощью функции isc_wait _for_event().

Приложение ESQL использует EVENT INIT для сообщения, что оно прослушивает событие, и EVENT WAIT, что оно ожидает оповещения. Оно прослушивает оповещение через вспомогательный канал между портами сети, используя главный дескриптор канала соединения с базой данных. Когда вызывается EVENT WAIT, выполнение клиентского приложения приостанавливается, пока не придет сообщение о событии.

Рис. 32.3. Синхронная сигнализация

Клиент в сети посылает изменение строки таблицы MYTABLE. Его принимает и обрабатывает сервер. В процессе фазы AFTER UPDATE триггер посылает сообщение с именем big_event для оповещения менеджера событий, что изменение завершено.

Менеджер событий добавляет это событие в список своих событий. В это время изменение не подтверждено, и менеджер событий больше ничего не делает. В своем списке прослушивающих он отыскивает процесс x, который прослушивает это событие. Процесс x будет ожидать, пока не подтвердится одно или более событий big_event.

При выполнении COMMIT менеджер событий посылает процессу x и всем другим процессам, ожидающим событие big_event, оповещение, что big_event произошло. Даже если транзакция много раз отправляла big event, ожидающие клиенты получат одно оповещение.

Если ни один процесс не зарегистрировал интерес в big_event, менеджер событий просто игнорирует POST_EVENT. Все процессы, к настоящему моменту выдавшие EVENT_WAIT для big_event, получат оповещение немедленно. Если какой-нибудь процесс зарегистрировал свой интерес в big_event, но не ожидает этого события, менеджер событий оставляет это событие, пока процесс либо не просигнализирует об ожидании, либо не отменит свой интерес. Если заинтересованные приложения потеряют интерес, событие big_event будет удалено из этой таблицы.

Приложение может ожидать не более 15 событий в одном запросе EVENT INIT. Оно может распределить события между несколькими запросами EVENT INIT, однако в случае синхронизированных событий оно может ожидать обработки только одного запроса EVENT INIT В каждый момент времени.

Асинхронная сигнализация

Асинхронная сигнализация имеет свои ограничения. В частности, она требует, чтобы приложение ожидало оповещения бесконечное время. Это ограничение модели было устранено при поддержке асинхронной сигнализации.

В этой модели приложение также регистрирует интерес и продолжает ожидать и прослушивать, однако оно способно продолжать собственное выполнение и выполнять запросы к базе данных в процессе ожидания оповещений. Приложение имеет свою собственную очередь событий, которой оно управляет на клиентской стороне. Рис. 32.4 описывает элементы установки асинхронного прослушивания.

Приложение для биржи, например, требует постоянного доступа к базе данных STOCKS для обеспечения брокеров в реальном времени информацией об изменении цен, однако оно также должно постоянно просматривать отдельные акции и переключать соответствующую процедуру Buy (купить) или sell (продать) при появлении некоторых событий.

Приложения DSQL используют вызовы API для прослушивания событий как синхронных, так и асинхронных. В DSQL не существует для них эквивалентов, а установка для интерфейсов приложений сырых составных частей является довольно сложной.

Приложение регистрирует интерес в событиях с помощью буфера параметров событий (Events Parameter Buffer, EPB), который заполняется при вызове функции isc_event_block(). Один EPB может регистрировать не более 15 событий, задавая различные EPB и список событий для каждого вызова. Именованные события должны соответствовать (с учетом регистра) событиям, которые будут отправлены. Приложения, которым нужно отвечать более чем на 15 событий, могут выполнить несколько вызовов isc_event_block().

Синхронное прослушивание с помощью API

Установка синхронного прослушивания через API похожа на то, что вы должны сделать для асинхронной сигнализации за исключением того, что при этом вызывается

функция isc_wait_for_event() вместо isc_que_event(). Как и в случае с эквивалентом в ESQL, EVENT WAIT, выполнение программы приостанавливается на время ожидания. Функция isc_wait_for_event() прослушивает оповещение, которое появится, когда сервер выполнит функцию обратного вызова.

Асинхронное прослушивание

Прежде чем вы сможете использовать функцию сигнализации API isc_que_evento, вам нужно выполнить функцию обратного вызова на клиенте, которую вызывал бы сервер при посылке события. Названием для такого типа функции является асинхронный перехват, или AST.

Функция AST

Функция AST предоставляет некоторую форму глобальных флагов для оповещения приложения, когда к нему обращается сервер. Она обрабатывает список событий сервера в буферах, к которым приложение может иметь доступ при управлении собственной очередью событий. Функция должна получать три аргумента:

* копию списка отправленных событий;

* длину буфера events_list;

* указатель на буфер events_iist.

Документ InterBase API Guide^[128] содержит рекомендации по написанию функций AST.

Функция isc_event_biock() принимает в своем параметре isc caiiback указатель на функцию AST и в своем параметре event_function_arg- указатель на первый аргумент AST. Этот аргумент обычно получает значение счетчика событий, когда они изменяются.

Когда приложение вызывает функцию isc_que_events о для сообщения о событиях, которые оно будет ожидать, оно передает вместе со списком указатель на функцию обратного вызова AST. Один вызов isc_que_events() может содержать до 15 событий. Приложение вызывает функцию isc_event_counts() для определения того, какое событие произошло.

Множество вызовов isc que eventso может выполняться одновременно в одном процессе клиент-сервер. Приложения отключают режим ожидания при вызове функции isc_cancel_events().

! ! !

ПРИМЕЧАНИЕ. Подробности установки блока событий для синхронного прослушивания через isc_event_wait() такие же. События не являются постоянными, как при асинхронной технике isc_que_events(). Синхронная сигнализация не требует внешней функции AST.

. ! .

Компонентные интерфейсы

К счастью, почти для всех из нас фрагменты кодов для реализации событий в клиентских приложениях инкапсулированы в классах и компонентах в большинстве инструментов разработки приложений, которые поддерживают Firebird. Такие компоненты, включающие в себя AST, инкапсулирующие вызовы функций API isc_event* вместе с блоками параметров событий и управление буферами событий на клиентской стороне, обычно называются обработчиками сообщений (event alerter). Иногда этот термин в форумах и литературе вызывает путаницу, потому что триггеры и хранимые процедуры, вызывающие POST_EVENT, также часто называют обработчиками сообщений.

Использование POST_EVENT

Для использования обработчика сообщений в хранимой процедуре или триггере применяйте следующий синтаксис:

POST_EVENT <имя-события>;

Параметр <имя-события> может быть или литералом в кавычках, или строковой переменной. Он является чувствительным к регистру и может начинаться с цифры. Имена событий ограничиваются 64 символами.

При выполнении процедуры этот оператор сообщает о событии менеджеру событий, который сохраняет его в таблице событий. При подтверждении транзакции менеджер событий информирует приложения, ожидающие это событие. Например, следующий оператор посылает событие с именем new_order:

POST_EVENT ‘ new_order’ ;

В альтернативном варианте, при использовании переменной для имени события можно одним оператором посылать различные события в соответствии с текущим значением строковой переменной (например, event_name).

POST EVENT event name;

! ! !

ПРИМЕЧАНИЕ. Хотя POST_EVENT и является оператором SQL, его аргумент имя события не должен иметь префикс двоеточия.

. ! .

Триггер или хранимая процедура, которые посылают сообщение, иногда называются обработчиками сообщений^[129]. Следующий скрипт создает триггер, который посылает событие менеджеру событий, когда любое приложение добавляет в таблицу данные:

SET TERM А;

CREATE TRIGGER POST_NEW_ORDER FOR SALES ACTIVE AFTER INSERT POSITION 0

BEGIN

POST_EVENT ‘new_order’; END ^

SET TERM ; ^

Триггер или процедура?

Оператор POST EVENT доступен и в триггерах, и в хранимых процедурах. Как же решить, где лучше его поместить для посылки событий?

Эмпирическим правилом является использование триггеров, когда приложениям нужно знать о событиях на уровне строки — одной строки или множества строк, в зависимости от области действия транзакции, — и процедур для сигнализации о таких событиях, которые воздействуют на приложения в целом.

Это только общие соображения — часто процедуры имеют область действия на уровне строки, и если заинтересованные клиенты хотят знать, когда произошла конкретная операция, событие посылается в такой хранимой процедуре. В этом случае POST_EVENT в триггере не будет иметь возможности ничего сообщить приложениям о контексте события. Разработчик может использовать события в процедуре, чтобы установить, какое приложение ответственно за выполнение соответствующей работы. В другом варианте разработчик может поместить сообщение о событии в триггер, чтобы гарантировать, что конкретное действие DML будет информировать всех, независимо от контекста, в котором оно выполняется.

Пора дальше

Теперь мы обратимся к безопасности вашего сетевого окружения СУБД. В этой части мы рассмотрим риски и меры безопасности, связанные с выполнением ваших серверов баз данных Firebird. Для начала в следующей главе обсуждаются некоторые слабые места в системе защиты операционного окружения и меры, которые вы можете принять по их устранению.

ЧАСТЬ VIII. Безопасность.

ГЛАВА 33. Безопасность в операционной среде.

В Firebird не существует средств для шифрования и дешифрования данных (кроме паролей пользователей), которые передаются через клиентский интерфейс. Существуют некоторые ограничения в использовании инструментов Firebird, которые осуществляют доступ к базам данных, но, в конечном счете, на уровне программного обеспечения нет защиты от налетчиков, которые установили доступ к вашей базе данных без авторизации.

В этой главе на первый план выдвигаются некоторые вопросы, по поводу которых вы должны предпринять меры предосторожности в вашем окружении сервера и клиентов Firebird. Не имеет никакого смысла выполнять проектирование для решения всех относящихся к безопасности окружения вопросов, которые могут воздействовать на ваш сервер и вашу сеть. Короче говоря, если безопасность имеет серьезное значение для установки вашей системы, то и отнеситесь к ней серьезно. Исследуйте ее, определите потенциальные зоны рисков и будьте готовы консультироваться со специалистами.

В главах 34 и 35 рассматриваются средства Firebird по управлению доступом на уровнях сервера Firebird и баз данных, соответственно. Глава 36 содержит подробности конфигурирования серверов Firebird для уменьшения незащищенности данных при некоторых рисках для безопасности, связанных с окружающей средой.

Физическая безопасность

Содержите серверы и чувствительные или критичные клиентские машины в помещениях с хорошо закрываемыми дверями. Если у вас на серверах или рабочих станциях установлена система FAT32, любой пользователь, локально подключившийся к одной такой машине, может получить доступ и ко всем другим. Если возможно, заблокируйте такие ресурсы, как CD-ROM, накопители на гибких магнитных дисках и драйверы Zip, отключите порты, через которые можно получить доступ к устройствам первоначальной загрузки или установите такие режимы в BIOS, которые предотвратят загрузку со съемных устройств. Установите в BIOS защиту по паролю, чтобы предотвратить неавторизованные изменения режимов первоначальной загрузки. Установите защиту по паролю на все серверы и рабочие станции.

Основным фактором физической безопасности является защита чувствительных к безопасности машин от физических контактов неавторизованных лиц. Все остальное не даст никаких результатов, если посторонние могут получить доступ к машине и осуществить кражу, или если кто-то может открыть дверь в эту комнату и украсть накопитель на жестком диске, подключенный к серверу.

Использование защищенных файловых систем

Пользователям удаленных баз данных (клиентским приложениям) не нужны полномочия файловой системы по доступу к базам данных. Им не нужны и соответствующие полномочия по использованию внешних приложений для записи и чтения внешних файлов данных, которые связаны с таблицами. Вы можете объединить полномочия операционной системы и средства конфигурирования на сервере параметра ExternaiFiieAccess (firebird.conf) для уменьшения риска постороннего воздействия.

Пользователям встроенных приложений, включая локальное (Классическое) соединение в POSIX, требуются права по доступу к файлу базы данных и другим файлам, таким как файлы блокировок, протоколов, внешних таблиц и т.д. Это же относится и к любой учетной записи того пользователя, который запускает сервер Firebird как приложение.

Защитите каталоги Firebird и другие каталоги, к которым обращается Firebird, используя максимально возможные ограничения, поддерживаемые вашей операционной системой и выбранной вами файловой системой.

Не храните программные файлы Firebird, базы данных, скрипты, оперативные копии или файлы данных внешнего доступа в разделах FAT32. В Windows не позволяйте использовать эти разделы обычным пользователям. Полномочия по использованию разделов NTFS, хранящих связанные с Firebird файлы и программы, должны быть максимально ограничены, насколько это возможно.

Использование групповых учетных записей предпочтительнее индивидуальных учетных записей. Где только возможно, исключите членство во множестве групп.

Защита оперативных копий

Регулярно выполняйте резервное копирование, упаковывайте копии, копируйте на переносимые носители и сохраняйте в защищенном месте.

Не оставляйте резервные копии и архивы базы данных в сетевом окружении, где гуляющие по сети могут их найти. Сворованная копия файла gbak может быть восстановлена с полной прозрачностью всех данных на любом другом сервере Firebird. Это означает, что если вы позволите мне украсть копию вашей базы данных или позволите получить файл gbak, я смогу восстановить это на моем сервере. Как пользователь SYSDBA, я смогу открыть и просмотреть все, что угодно.

Некоторые ложные предположения

Пара ложных предположений используется бестолковыми администраторами базы данных, мало беспокоящимися о защите базы данных и файлов резервных копий.

* Файл копии разрушен, следовательно, он не может быть использован злоумышленником. Не думайте, что файл копии выполняющейся базы данных будет разрушен и недоступен для использования. Незаконная копия прекрасно может быть использована, особенно если деятельность по изменению данных базы данных выполняется относительно редко, или если атакующий попытается выполнить повторные копирования^[130].

* Файлы gbak не являются базами данных, следовательно, не могут быть использованы злоумышленником. Любой может восстановить базу данных из копии вашего файла gbak.

Защита, основанная на возможностях платформы

Тот уровень защиты, основанный на платформе, который вы можете использовать при инсталляции вашего сервера базы данных, зависит от двух факторов: как хорошо платформа операционной системы и ее файловая система могут защитить вашу систему (программы и данные) и насколько безопасной должна быть ваша система. Второе может быть хорошим основанием для выбора первого.

Если у вас есть очень веские причины поступить иначе, вам следует запустить сервер Firebird как сервис.

Если возможно, используйте специальную учетную запись пользователя для запуска сервиса Firebird. В Firebird 1.5 это реализовано по умолчанию для Linux и некоторых других POSIX-систем. Под Windows и для Firebird 1.0.x вы должны это сделать сами.

Ограничение подключения к операционной системе

Требуйте пароли при всех подключениях и отменяйте кэширование подключения на серверах и рабочих станциях Windows. В сетях отменяйте возможность для пользователей и групп изменять их собственные установки регистрации. Задавайте строгие пароли. Усиливайте блокировки учетных записей на всех серверах и рабочих станциях, которые соединяются с базами данных.

Заставьте использовать обычные учетные записи при нормальной работе. Ограничьте подключения root или администратора административными сессиями. Отключите учетные записи «guest», «world» и «everyone».

Отслеживайте неверные подключения, ошибки при отключениях, ошибки при доступе к объектам файлов и программ, нарушения пользовательских привилегий, необычные завершения и перезагрузки системы.

POSIX

Linux, UNIX и другие платформы POSIX более предпочтительны, чем Windows, если требуется высокая безопасность. Технологии безопасности этих платформ являются продуманными и очень понятными в реализации. Безопасность файловой системы и надежный доступ присущи требованиям проектирования, которые определены в общих стандартах. Это не означает, что просто инсталляция сервера баз данных на платформе POSIX является гарантией безопасности. Это говорит о том, что тут существуют элементы, необходимые для установки систем безопасности, обеспечивающих надежную защиту.

Платформы Microsoft Windows

Инсталляции сервера Windows являются столь безобразно сложными в плане безопасности, что требования высокой защищенности могут просто полностью исключить Windows в качестве платформы для установки серверов базы данных, в которых оценка и отслеживание безопасности на местах отсутствует.

В презентации лаборатории, озаглавленной «Укрепление Windows 2000»^[131], гуру сетевой безопасности Philip Сох из SystemExperts Corporation начал очерчивать «Четыре шага практической безопасности в Win2K» следующим образом:

1. Локализовать систему Windows.

2. Вставить *nix CD.

3. Перезагрузиться.

4. Следовать подсказкам инсталляции.

Эти слова были сказаны с насмешкой, они сопровождались обязательными «улыбочками», но доклад Philip Сох содержит серьезный полезный совет системным администраторам, для которых запуск серверов Windows является лишь возможным вариантом. Он основной автор официальной и очаровательно искренней книги по безопасности сервера Windows «Windows 2000 Security Handbook»^[132]. Сама Microsoft публикует официальные издания с подробными практическими инструкциями по реализации безопасности на их серверных платформах и часто выпускает патчи безопасности. Сайт activewin.com является полезным источником связанных описаний множества патчей безопасности, которые были созданы и продолжают создаваться в различных версиях Windows.

Windows NT/2000 и XP

В системах Windows NT/2000 и XP сервисы доступны удаленным клиентам, даже когда ни один пользователь не соединен с сервером.

При выполнении сервис Firebird, как и большинство сервисов Windows, выполняется под учетной записью localsystem. Localsystem является встроенной учетной записью, которая для Windows NT 4 и меньших версий сервера имеет мало возможностей. На более поздних серверных платформах Windows localsystem была наделена чрезмерным уровнем привилегий доступа к локальным системным ресурсам, включая привилегии, которые не могут быть предоставлены даже членам группы администраторов.

Приложения же выполняются под обычными учетными записями пользователей и требуют, чтобы пользователь был соединен с сервером. Любой стандартный пользователь Windows может запустить сервер Firebird как приложение.

Защита файлов

Под Windows строго рекомендуется ограничить размещение каталогов (папок), где располагаются файлы базы данных и компоненты сервера, и защитить к ним доступ. Установите права к объектам и полномочия для совместно используемого ресурса для каждого файла, к которому потенциально могут обращаться сетевые пользователи. Чтобы быть защищенными, каталоги и файлы должны находиться в разделах NTFS, в деревьях, предназначенных для этих целей, и должны быть сделаны читаемыми только для учетной записи или группы с соответствующими привилегиями.

Когда доступ по чтению ограничен таким образом, удаленные клиенты обязаны соединяться с сервером через протокол TCP/IP, но не через Windows Networking (часто называемый NetBEUI).

Дополнительно для Firebird 1.5 и выше вы можете (и должны) ограничить локализацию, где сервер может читать файлы базы данных с помощью параметра DatabaseAccess в файле конфигурации firebird.conf.

Windows 95/98 и ME

Когда безопасность является важной, системы Windows 95/98 и ME не должны рассматриваться для использования в качестве хоста для Firebird. Они не имеют поддержки сервисов или безопасности на уровне файлов. Любой человек, имеющий доступ к файловой системе, может легко сделать копию базы данных с помощью команды копирования или архивирования файлов или просто использовать возможности GUI (Drag-and-Drop, копировать и вставить и т.д.) для воровства базы данных Firebird.

Возможность В Firebird 1.5 конфигурировать ограничение DatabaseAccess в файле firebird.conf (см. главу 36) доступна на этих «не серверных» платформах. По крайней мере, это ограничит размещение каталога, в котором сервер сможет читать файлы базы данных. При этом файловая система FAT32 открыта всему миру и не предоставляет никакой защиты от случайного или намеренного перезаписывания баз данных, кодов внешних функций или других файлов, связанных с Firebird.

Выполнение произвольного кода

Для плохо защищенных систем все текущие версии Firebird предоставляют возможность выполнения произвольного кода с помощью внешних функций, фильтров BLOB и реализаций пользовательских наборов символов. Такие внешние модули выполняются в том же адресном пространстве, что и серверный процесс, и с теми же привилегиями.

Соответственно, важно защитить сервер от возможности доступа внешних файлов и модулей, написанных неавторизованными пользователями.

Firebird 1.0.x

В Firebird 1.0.x вы можете сконфигурировать указанные каталоги для хранения внешних модулей и внешне отображаемых файлов данных и применить ограничения на уровне операционной системы для предотвращения неавторизованного доступа. Настоятельно рекомендуется использовать такую возможность в файловых системах, которые способны это поддерживать с полномочиями доступа файловой системы.

При этом сервер Firebird 1.0.x имеет доступ к внешнему коду и данным в любом месте файловой системы, находящейся под управлением хоста.

Firebird 1.5

В версии 1.5 и выше размещение внешних выполняемых модулей и других внешних объектов может быть жестко сконфигурировано для гарантии того, что сервер вызовет исключение, если получит запрос на доступ к внешним объектам, расположенным не в нужном месте. Подробности такого конфигурирования см. в замечаниях относительно внешних объектов в конце главы 36.

Особые риски, связанные с сервисами Windows

Сервисы, выполняемые под профилем localsystem, рассматриваются как часть надежного базового кода (Trusted Code Base, TCB) — предполагается, что они имеют такой же уровень надежности, что и сама Windows. Выполнение сервиса Firebird в Windows 2000 и выше несет в себе явный риск в отношении выполнения произвольного кода, созданного со злым умыслом. Важность обеспечения программной целостности внешних выполняемых модулей Firebird, даже при очень высоких условиях безопасности, является критичной.

Короче говоря, программное обеспечение операционной системы Windows не дает надежных гарантий безопасности серверов базы данных в локальной сети или за ее пределами. Потенциально возможные внешние модули должны быть отключены четко сконфигурированным контролем доступа пользователей с помощью LAN и надежными продуктами сетевой защиты сторонних разработчиков для определения и блокирования атак.

Встроенный сервер под Windows

Библиотека встроенного сервера под Windows, естественно, разработана для работы на машинах, которые не используются как полноценный сервер. Если у вас есть копия библиотеки fbembed.dll, расположенная где-нибудь на полностью серверной машине, безопасность сервера подвергается большому риску. И вот почему.

Встроенный сервер не использует идентификацию сервера для проверки, имеет ли на это права пользователь, подключающийся к базе данных. Большинство интерфейсов приложений требуют имени и пароля пользователя. Подойдет любое имя пользователя и любой пароль — ничего проверяться не будет. Внутренняя безопасность базы данных, разработанная для использования во встроенном сервере, может быть обеспечена разрешениями SQL (см. главу 35), которые ограничивают доступ, разрешая его конкретному пользователю. Это само по себе является дырой в безопасности на отдельно взятой машине, которая физически доступна для любого «прохожего».

При этом на машине, где выполняется сервер Firebird 1.5 и установлено программное обеспечение встроенного сервера, хакерская программа может быть запущена под встроенным сервером, когда базы данных закрыты, может соединиться с файлом security.fdb как пользователь SYSDBA, украсть или разрушить пользовательские записи, прочесть зашифрованный пароль и обратиться к другим базам данных, как SYSDBA. Когда приложение соединяется с базами через fbembed.dll, оно блокирует каждую базу данных. Хакерское приложение может сохранять соединения с базами данных — включая security.fdb — бесконечно долго.

Приложения встроенного сервера и клиенты выполняются в адресном пространстве операционной системы пользователя. Для исключения риска попадания в систему злонамеренных программ встроенного сервера ограничьте доступ пользователя и группы в файловой системе пространством, где располагаются базы данных и системные файлы Firebird.

Безопасность сетевого соединения

Множество сообщений между клиентом и сервером несет информацию, которая может быть довольно легко получена кем-то, подслушивающим сетевые сообщения. Например, зашифрованный пароль может быть получен и использован для неавторизованного доступа к серверу.

Поэтому необходимо, чтобы все части сетевого пути между клиентом и сервером были под контролем.

Можно приобрести дополнительные продукты для зашифрованной передачи данных по сети, чтобы блокировать незащищенные цепи^[133].

Web и другие многозвенные серверные приложения

Попытка полагаться на имена пользователей по умолчанию может привести к непредвиденным результатам, таким как неожиданная передача привилегий владельца базы данных или даже владельца

серверного процесса обычным пользователям. Строго рекомендуется, чтобы ваше серверное приложение требовало ввода имени пользователя и пароля до каких-либо обращений к серверному процессу Firebird.

Использование выделенных серверов

Исключите использование на хост-машине других сервисов, особенно таких уязвимых, как серверы Web и FTP, которые потенциально принимают безымянные подключения. Отключение других сервисов не требуется для запуска Firebird. В Windows ограничьте сетевой доступ к реестру на серверах баз данных.

Использование средств межсетевой защиты

По очевидным причинам рекомендуется размещение ваших серверных машин под управлением средств межсетевой защиты (firewall). Может быть менее очевидным то, что использование средств межсетевой защиты клиентских процессов также является хорошей идеей. Неконтролируемый пользователь может запустить процесс на надежной клиентской машине для передачи некорректной информации серверу и получить привилегированный доступ к его базам данных. Известно, что клиенты Windows ненадежны.

Отражение атак

Код Firebird 1.0.x содержит большое количество команд копирования строк, которые не проверяют длину копируемых данных. Некоторые из этих переполнений могут быть доступны для внешнего манипулирования путем передачи больших строк двоичных данных в операторах SQL или «проталкивания» произвольного мусора в порт сервера (в настоящий момент 3050). Использование таких функций является общей техникой для попыток переполнения буфера с целью взлома серверов.

Такая уязвимость проще реализуется, если серверный и клиентский процессы выполняются не в надежной сети и/или без использования адекватной межсетевой защиты.

Защищенное программирование может помочь в превентивном отражении атак на вашу систему. Например, проверка длины получаемой строки может оказаться особенно полезной.

Пора дальше

В следующей главе обсуждается защита, предоставляемая (или не предоставляемая) средствами сервера Firebird безопасности баз данных, вместе с использованием инструмента gsec для управления списком доступа пользователей на сервере. Глава заканчивается специальной темой настроек безопасности баз данных для улучшения некоторых аспектов такой встроенной защиты.

ГЛАВА 34. Защита сервера.

Инсталляция сервера включает базу данных идентификации пользователя для хранения описания всех пользователей, которые имеют доступ к серверу Firebird. Чувствительный к регистру пароль должен быть определен для каждого пользователя и должен быть использован для доступа к серверу. Инструментом командной строки для поддержки пользователей баз данных является gsec.

Именем базы данных безопасности для Firebird 1.5 и выше является security.fdb. В версии l.O.x это файл isc4.gdb. Он должен размещаться в корневом каталоге Firebird для всех инсталляций сервера за исключением встроенного сервера для Windows^[134].

Идентификация пользователя требуется, когда удаленный или локальный клиент соединяется с базой данных Firebird. Единственным исключением является случай, когда клиент соединяется через приложение встроенного сервера в Windows. В этой ситуации база данных потребует имя пользователя, соответствующее разрешениям SQL, определенным для ее объектов. Не будет выполняться никакой идентификации имени/пароля пользователя при соединении встроенного процесса клиент-сервер.

Ввод учетных данных пользователя

Основное использование gsec — или интерфейса gsec — ввод учетных данных пользователя. Интерфейс gsec шифрует пароли перед их сохранением. Не соединяйтесь из пользовательского приложения или из инструмента администратора непосредственно с базой данных безопасности для запуска скрипта с целью «пакетного ввода» пользователей, потому что пароль в этом случае будет сохраняться в виде чистого, незашифрованного текста.

! ! !

СОВЕТ. В Firebird существуют сервисы API, которые связываются в gsec вместе с другими инструментами командной строки. Некоторые инструменты администратора сторонних разработчиков предоставляют доступ к gsec для поддержания учетных данных пользователей через сервисы API в более дружественном интерфейсе, чем утилиты командной строки.

. ! .

Требуемыми данными являются имя пользователя и пароль. Для имен пользователей и паролей в настоящий момент не поддерживаются международные наборы символов.

Только пользователь SYSDBA может обслуживать базу данных безопасности. Это означает, что вновь установленный Firebird не поддерживает изменения пользователями своих собственных паролей. Техники настроек идентификации пользователей на вашем сервере и реализацию этих возможностей см. в разд. «Специальная тема» в конце этой главы.

Имя пользователя чувствительно к регистру и должно быть уникальным. В настоящий момент оно может содержать только символы, допустимые для идентификаторов объектов: А-2 (или а-z), цифры и символы !, #, $, &, @. Теоретически имя пользователя может содержать до 128 символов, но вы должны рассматривать его ограниченным 31 символом, потому что более длинное имя не будет верным при использовании разрешений SQL.

! ! !

ВНИМАНИЕ! gsec позволит вам определять глупые имена пользователей, такие как строки звездочек или «смайлики» вроде :), однако не прельщайтесь этим! Подобные строки неприемлемы на месте, где используются имена пользователей — в параметрах соединения или операторах разрешения.

. ! .

Пароль может содержать до 32 символов, однако только первые восемь являются значимыми. Поэтому, например, пароли masterkey и masterkeeper для сервера выглядят идентичными. Пароли чувствительны к регистру. Допустимые символы такие же, как и для имени пользователя, но прописные буквы отличаются от строчных. Пароли не обязаны быть уникальными, хотя это и желательно для целей повышения безопасности.

! ! !

ПРИМЕЧАНИЕ. Некоторые интерфейсы администратора накладывают ограничение в восемь символов и не допускают имена пользователей и пароли, которые начинаются с цифры. Хотя это и не является ограничением системы безопасности баз данных, имеет смысл следовать такой практике.

. ! .

Шифрование пароля

Интерфейс gsec шифрует пароли, используя скромный метод, основанный на алгоритме хэширования DES (Data Encryption Standard, стандарт шифрования данных). По причине восьмисимвольного ограничения идентификация пользователя в Firebird на сегодняшний день не может рассматриваться как «центурион у ворот в современную эпоху»^[135].

Все-таки исключите такие очевидные пароли, как password и sesame. Смешивайте регистр, включите цифры и обеспечьте регулярное изменение паролей.

! ! !

СОВЕТ. Поскольку невозможно отыскать потерянные пароли с помощью запросов к системе, вам нужна непробиваемая система фиксации паролей пользователей при их изменении. Глупая болтовня про отслеживание пользователей не может быть той системой, которую осознанно выбирает организация для средств безопасности! Потеря паролей может быть восстановлена пользователем SYSDBA. Если же будет потерян пароль у SYSDBA, то вся база данных безопасности должна быть заменена путем восстановления файла security.fdb, который вы найдете в корневом каталоге Firebird (для Firebird 1.0.x это файл isc4.gdb). Начните работу с паролем masterkey.

. ! .

Учет пользователей в SQL

Поскольку пользователи Firebird поддерживаются на уровне сервера, не существует никакого специального SQL-оператора для этого. Причем имена пользователей используются в SQL в качестве аргументов операторов GRANT … ТО и REVOKE … FROM. Подробности см. в главе 35.

Имя пользователя также доступно во множестве выражений SQL через контекстную переменную CURRENT_USER и серверный литерал USER.

Пользователь SYSDBA

Новые инсталляции Firebird для Windows устанавливают в базу данных безопасности пользователя SYSDBA с паролем masterkey. Очевидно, что это известно всем, и не может использоваться для безопасности. Пароль должен быть изменен в первую очередь.

Под Linux некоторые инсталляторы способны генерировать произвольный пароль для SYSDBA. Вы можете увидеть его в текстовом файле SYSDBA.password, размещенном в каталоге Firebird /bin.

Пользователь SYSDBA является владельцем базы данных безопасности. Помните, что базы данных Firebird имеют «одного пользователя SYSDBA для управления всеми». Пользователь SYSDBA имеет все деструктивные права ко всем базам данных на сервере. Пароль у SYSDBA не должен распространяться на обычных пользователей.

Слабое место POSIX

Firebird может допустить соединения клиентов с серверами на платформах POSIX, при которых обходится идентификация пользователя Firebird, а вместо этого используется схема разрешений для пользователя операционной системы. Это давно существующая возможность, наследованная от InterBase. Незнание данного факта оставляет большую дыру в безопасности на платформах POSIX, если путь доступа пользователя POSIX будет широко открыт, а системный администратор будет ошибочно предполагать, что база данных безопасности является максимально защищенной.

Это не так. Когда пользователи POSIX соединяются с базой данных без передачи серверу Firebird имени пользователя и пароля, подпрограмма идентификации подставляет текущие характеристики операционной системы вместо характеристик пользователя Firebird. Если пользователь операционной системы имеет привилегии root, опасайтесь, очень опасайтесь.

Поскольку пользователи POSIX могут получить доступ к базам данных Firebird через их учетные данные операционной системы, важно определить надежные взаимосвязи между сервером и каждой клиентской рабочей станцией. Это переводится в записи в /etc/host.equiv или в другие данные, такие как файл .rhost в домашнем каталоге пользователя на сервере.

! ! !

СОВЕТ. Читатель также может поэкспериментировать с файлом /etc/gds_host.equiv — см. текст «Installing InterBase to start automatically and run as a service under Linux» (Инсталляция InterBase для автоматического запуска и выполнения в качестве сервиса под Linux) у Richard Combs на http://community.borland.eom/article/0,1410,27761,00.html.

. ! .

Переменные окружения ISC_USER и ISC_PASSWORD должны быть исключены из системы.

! ! !

ВНИМАНИЕ! Автору не известны способы определения надежной взаимосвязи между рабочей станцией Windows и сервером UNIX, но это не означает, что такое не может быть сделано.

. ! .

Утилита gsec

В Firebird существует утилита gsec в качестве интерфейса командной строки для работы с базой данных безопасности. Она имеет собственную оболочку для интерактивного использования, либо команда gsec может быть непосредственно введена в командной строке операционной системы или запущена из исполняемого скрипта (скрипта командной строки или пакетного файла).

Любой идентифицированный пользователь может запустить gsec, но только пользователь SYSDBA может изменять сведения о пользователе, хранящиеся в базе данных безопасности. Требуются имя пользователя и пароль, независимо от того, видимы ли из командной строки переменные окружения ISC_USER и ISC_PASSWORD. В POSIX, если вы подключились как root, вы можете вызывать gsec без ввода параметров -user и -password.

Запуск интерактивной сессии gsec

В командной строке в каталоге Firebird /bin введите следующее. Для POSIX:

./gsec -user sysdba -password masterkey

Для Windows:

gsec -user sysdba -password masterkey

Подсказка командной строки изменится на GSEO, указывающую, что вы запустили gsec в интерактивном режиме.

Для завершения интерактивной сессии введите QUIT.

Запуск gsec как удаленного клиента

SYSDBA может использовать gsec на клиентской машине для управления идентификацией пользователей на удаленном сервере. Синтаксис вызова в этом случае несколько отличается: он требует переключателя -database, за которым следует полный сетевой путь к базе данных безопасности. Например (это одна команда), здесь показывается, как клиент POSIX обращается к серверу Windows в версии 1.5:

./gsec -database hotchicken:с:Program FilesFirebirdFirebird_1_5security. fdb

-user sysdba -password masterkey

Следующий пример показывает обращение клиента Windows к серверу POSIX в версии 1.0.x:

gsec -database coolduck:/opt/firebird/isc4.gdb

-user sysdba -password masterkey

Интерактивные команды

Командами интерактивной утилиты gsec являются отображение, добавление, модификация, удаление, помощь и выход. Они не чувствительны к регистру.

* add, modify и delete используются для добавления и удаления пользователей и для изменения паролей. Они требуют в качестве параметра имя пользователя (username) вместе с соответствующими переключателями и аргументами.

* display без имени пользователя отображает список всех пользователей. Пароли не показываются. Эта команда также может получать имя пользователя. В этом случае отображаются подробности этого пользователя.

* help или его алиас ? отображает текст помощи для утилиты.

* quit завершает gsec и закрывает командную строку.

Таблица USERS и режимы gsec

В табл. 34.1 показаны столбцы таблицы USERS вместе с соответствующими переключателями gsec. Требуемыми полями при использовании gsec являются только

USER NAME и PASSWD.

Таблица 34.1. Столбцы таблицы USERS и режимы gsec

Столбец	Описание	Режим gsec	Аргумент
USER_NAME	Имя пользователя, распознаваемое идентификацией пользователя на сервере, gsec требует его в качестве параметра для интерактивных команд добавления, изменения и удаления и для соответствующих переключателей командной строки -a[dd], mo[dify] и-d[elete]		username параметр
SYS_USER_NAME	Не используется
GROUP_NAME	Не используется
UID	Для некоторых платформ POSIX идентификатор пользователя UNIX. Не требуется	-uid	integer
GID	Для некоторых платформ POSIX идентификатор группы UNIX. Не требуется	-gid	integer
PASSWD	Текущий пароль для этого пользователя. Требуется	-pw	string(10)
PRIVILEGE	Не используется
COMMENT	Не используется
FIRST_NAME	Имя пользователя. Не требуется	-fname	string(31)
MIDDLE_NAME	Второе имя пользователя. Не требуется	-mname	string(31)
LAST_NAME	Фамилия пользователя. Не требуется	-Iname	string(31)
FULL_NAME			Нет
	Также при запуске gsec с удаленной рабочей станции:
	Сервер и путь к файлу базы данных безопасности	-database	Путь и имя файла

Примеры gsec

display

Отображает основные столбцы таблицы USERS базы данных безопасности. Пароли никогда не показываются.

user_name uid gid full name SYSDBA

MICKEY 123 345 Mickey Mouse

D_DUCK 124 345 Donald Duck

JULIUS 125 345 J. Caesar

Для отображения той же информации из одной строки таблицы USERS введите:

GSEC> display username

Например:

GSEC> display julius user_name uid gid full name

JULIUS 125 345 J. Caesar

a[dd]

Добавляет пользователя в таблицу USERS:

a[dd] имя-пользователя -pw пароль [другие переключатели]

Здесь имя-пользователя- уникальное новое имя пользователя, а пароль- пароль, связанный с этим пользователем.

! ! !

ПРИМЕЧАНИЕ. Переключателем для нового пароля при добавлении пользователя или при изменении его пароля является -pw. Не путайте его с сокращенной формой переключателя пароля при соединении SYSDBA, который задается в виде -ра.

. ! .

Пример:

GSEO add mmouse -pw Veritas

Для добавления пользователя hpotter с именем Harry Potter и паролем noMuggle введите:

GSEC> add hpotter -fname Harry -lname Potter -pw noMuggle

Для проверки новой записи:

GSEC> display hpotter

user_name uid gid full name

HPOTTER Harry Potter

! ! !

ПРИМЕЧАНИЕ. Если вы попытаетесь ввести недопустимые символы в строке пароля, gsec просто завершит работу без выдачи сообщения.

. ! .

mo[dify]

Используется для изменения (редактирования) значения столбца в существующей записи USERS. Задайте имя пользователя, для которого требуются изменения, затем укажите один или более переключателей, определяющие изменяемые элементы, и новое значение для каждого из них.

Например, для задания идентификатора пользователя 25 для пользователя mickey, изменения имени (first name) на Michael и изменения пароля на icecream введите следующие переключатели:

GSEC> modify mickey -uid 25 -fname Michael -pw icecream

Вы не можете изменить имя пользователя. Удалите старого пользователя и добавьте нового.

de[lete]

Удаляет пользователя с указанным именем из таблицы USERS. Команда не получает никаких аргументов и переключателей.

de[lete] имя-пользователя Пример:

GSEO delete mickey

Вы можете использовать команду display, чтобы убедиться в удалении записи.

h[elp] или ?

Любой из этих переключателей позволяет отобразить общие сведения о командах gsec, переключателях и синтаксисе.

q[uit]

Завершает интерактивную сессию.

Использование gsec из командной строки

Для использования gsec из командной строки преобразуйте каждую команду gsec в командный переключатель, добавив префикс в виде знака минус (-). Переключатели остаются теми же самыми.

Например, для добавления пользователя claudio и назначения ему пароля dbkeycop в командной строке введите следующее.

В Windows:

,.BIN> gsec -add claudio -pw dbkeycop -user SYSDBA -password masterkey

В POSIX:

bin]$ ./gsec -add claudio -pw dbkeycop -user SYSDBA -password masterkey

Для отображения содержимого таблицы USERS введите: > gsec -display и так далее.

Сообщения об ошибках gsec

В табл. 34.2 представлены сообщения об ошибках gsec.

Таблица 34.2. Сообщения об ошибках gsec

Сообщение	Причины и рекомендуемые действия
Add record error (Ошибка добавления записи)	Неверный синтаксис или вы пытаетесь добавить пользователя, который уже существует, или вы не являетесь пользователем SYSDBA. Используйте modify, если пользователь уже существует
<string> already specified (<строка> уже была задана)	Вы включили переключатель более одного раза в команду add или modify. Введите команду заново
Error in switch specifications (Ошибка в задании переключателя)	Это сообщение сопровождает другие сообщения об ошибках и указывает на то, что был использован неверный синтаксис. В этом случае просмотрите другие сообщения об ошибках
Find/delete record error (Ошибка поиска удаляемой записи)	Команда удаления не может найти указанного пользователя или вы не являетесь пользователем SYSDBA
Find/display record error (Ошибка поиска отображаемой записи)	Команда модификации не может найти указанного пользователя или вы не являетесь пользователем SYSDBA
Incompatible switches specified (Заданы несовместимые переключатели)	Например, вы ввели множество переключателей для команды удаления, которая требует только одного обязательного аргумента имя-пользователя. Скорректируйте синтаксис и выполните команду заново
Invalid parameter, no switch defined (Неверный параметр, не задан переключатель)	Вы указали значение без аргумента
Invalid switch specified (Задан неверный переключатель)	Вы задали нераспознанный переключатель. Исправьте и вновь выполните команду
No user name specified (He задано имя пользователя)	Задавайте имя пользователя после команд или переключателей добавления, изменения или удаления
Record not found for user: <string> (He найдена запись для пользователя: <строка>)	Запись указанного пользователя не найдена. Отобразите список пользователей и вновь введите команду
Unable to open database (Невозможно открыть базу данных)	База данных безопасности не существует или не может быть локализована на сервере. Запустили ли вы gsec вне каталога Firebird? Пытаетесь ли вы получить доступ к удаленному серверу, который не был инсталлирован?

Специальная тема: настройка безопасности пользователя

Идентификация пользователя Firebird довольно проблематична. Хорошая новость: все изменится к лучшему в Firebird 2. Плохая новость: нам придется с этим жить еще некоторое время. Ivan Prenosil- эксперт, в течение длительного времени занимающийся разработкой баз данных с использованием Firebird и его предшественников — создал несколько техник для настроек безопасности баз данных. Ivan согласился поделиться с вами своими советами и скриптами в данной специальной теме.

База данных безопасности

Когда пользователь соединяется с базой данных Firebird, его пароль сравнивается с зашифрованным паролем в базе данных безопасности. В версии 1.0.x имя базы данных isc4.gdb, в версии 1.5 — security.fdb. Это обычная база данных Firebird, таблица, используемая для идентификации пользователей, USERS. Ее (упрощенная) структура выглядит следующим образом:

CREATE TABLE USERS (

USER_NAME VARCHAR(128) ,

PASSWD VARCHAR(32) ); /* V

GRANT SELECT ON USERS TO PUBLIC;

Для проверки разрешений к этой таблице существует два очевидных препятствия. Одно — ни один пользователь не может прочесть полный список пользователей и зашифрованных паролей. Другое — только пользователь SYSDBA может изменять эту таблицу — пользователи не могут изменять их собственные пароли.

При этом, если вы пользователь SYSDBA, вы можете соединиться с базой данных безопасности, как и с любой другой базой данных, и изменять ее структуру. Это означает, что вы можете ее улучшать.

! ! !

ВНИМАНИЕ! Не забудьте сделать копию базы данных безопасности перед тем, как начнете ее изменять!

. ! .

Различие версий

При идентификации пользователей в Firebird 1.0.x сервер соединяется с базой данных безопасности, отыскивает необходимую информацию, а затем отсоединяется. Между соединениями у вас могут быть «не очень хорошие отношения» с isc4.gdb.

Однако в Firebird 1.5 соединение с базой данных безопасности сохраняется, пока пользователь соединен с любой базой данных на сервере. Поэтому в версии 1.5 вы должны выполнять все изменения с копией базы данных безопасности и позже ее инсталлировать. Нужно выполнить следующие шаги.

1. Сделайте оперативную копию security.fdb с использованием gbak.

2. Восстановите ее с другим именем.

3. Запустите скрипт для копии.

4. Закройте сервер.

5. Поменяйте местами старую и новую версии security.fdb и переименуйте.

6. Запустите заново сервер.

Предоставление пользователям возможности изменять свой собственный пароль

Самым простым и наиболее известным способом изменения является предоставление следующей привилегии изменения для пользователя, не являющегося SYSDBA, GRANT UPDATE ON USERS то PUBLIC и добавление триггера, предотвращающего изменение пользователем, не являющимся SYSDBA, пароля других пользователей.

Вот скрипт:

CONNECT ‘C:Program FilesFirebirdFirebird_1_5security.fdb’

USER ‘SYSDBA’ PASSWORD ‘masterkey’;

CREATE EXCEPTION E_NO_RIGHT ‘You have no rights to modify this user.’;

/* Вы не имеете прав для изменения этого пользователя */

SET TERM !!;

CREATE TRIGGER user_name_bu FOR USERS BEFORE UPDATE

BEGIN

IF (NOT (USER = ‘SYSDBA’ OR USER = OLD.USER_NAME)) THEN

EXCEPTION E_NO_RIGHT;

END ! !

SET TERM ;!!

/** Grants. **/

GRANT UPDATE (PASSWD, GROUP_NAME, UID, GID,

FIRST_NAME, MIDDLE_NAME, LAST_NAME)

ON USERS TO PUBLIC;

Довольно неуклюже предоставлять доступ ко всем столбцам, когда вам реально нужен доступ только к PASSWD. К сожалению, это необходимо, если ваше приложение собирается использовать gsec или сервис API.

Такая модификация не устраняет проблему видимости для PUBLIC полного списка пользователей и их зашифрованных паролей. Это позволяет пользователям очень просто получить список паролей других пользователей и постараться сломать их локально посредством грубой силы^[136].

Как спрятать список пользователей/паролей

Если вы переименуете таблицу USERS и заново создадите USERS как просмотр переименованной таблицы, вы можете получить лучший из миров. У пользователей будет возможность изменять свои собственные пароли, а полный список пользователей и паролей будет спрятан для PUBLIC. Каждый пользователь, не являющийся SYSDBA, будет видеть только одну запись из security.fdb (или isc4.gdb, если у вас сервер версии 1.0.x). Новые структуры в security.fdb будут похожи на следующую схему:

CONNECT ‘C:Program FilesFirebirdFirebird_1_5security.fdb’

USER ‘SYSDBA’ PASSWORD ‘masterkey’;

/** Переименование существующей таблицы USERS в USERS2. **/

CREATE TABLE USERS2 (

USER_NAME USER_NAME,

SYS_USER_NAME USER_NAME,

GROUP_NAME USER_NAME,

UID UID,

GID GID,

PASSWD PASSWD,

PRIVILEGE PRIVILEGE,

COMMENT COMMENT,

FIRST_NAME NAME_PART,

MIDDLE_NAME NAME_PART,

LAST_NAME NAME_PART,

FULL_NAME COMPUTED BY (first_name || _UNICODE_FSS »II middle_name || _UNICODE_FSS ‘ ‘ || last_name ) ) ;

COMMIT;

INSERT INTO USERS2

(USER_NAME, SYS_USER_NAME, GROUP_NAME,

UID, GID, PASSWD, PRIVILEGE, COMMENT,

EIRST_NAME, MIDDLE_NAME, LAST_NAME)

SELECT

USER_NAME, SYS_USER_NAME, GROUP_NAME,

UID, GID, PASSWD, PRIVILEGE, COMMENT,

EIRST_NAME, MI DDLE_NAME, LAST_NAME FROM USERS;

COMMIT;

/* */

DROP TABLE USERS;

/* */

CREATE UNIQUE INDEX USER_NAME_INDEX2 ON USERS2(USER_NAME);

/** Создание просмотра, который будет использован вместо первоначальной таблицы USERS. **/

CREATE VIEW USERS AS

SELECT *

FROM USERS2

WHERE USER = »

OR USER = ‘SYSDBA’

OR USER = USER_NAME;

/** Полномочия **/

GRANT SELECT ON USERS TO PUBLIC;

GRANT UPDATE (PASSWD, GROUP_NAME, UID, GID, FIRST_NAME, MIDDLE_NAME, LAST_NAME)

ON USERS

TO PUBLIC;

Реальная таблица USERS2 видима только для SYSDBA. Следующее условие

USER = USER_NAME

гарантирует, что каждый пользователь видит только свою собственную запись. Условие

USER = ‘SYSDBA’

гарантирует, что SYSDBA может видеть все записи. Условие

USER = ‘ ‘

является важным, потому что переменные USER и CURRENT_USER содержат пустые строки в процессе проверки пароля.

! ! !

ПРИМЕЧАНИЕ. К сожалению, две следующие техники не могут быть реализованы в сервере Firebird 1.5. Они используют запись в файлы протоколов. Улучшения безопасности, выполненные в версии 1.5, означают, что подпрограмма идентификации пользователя теперь выполняется в транзакции только для чтения, следовательно, невозможно выполнять запись в протокол! Похожая схема может быть реализована путем делегирования функции протоколирования внешним функциям.

. ! .

Как запротоколировать попытки соединения с базой данных

Замена таблицы USERS в базе данных безопасности на просмотр USERS имеет одно большое преимущество: она позволяет нам вызывать хранимую процедуру, когда пользователь пытается соединиться с базой данных. Когда сервер Firebird выполняет оператор

SELECT PASSWD FROM USERS

WHERE USER_NAME = ?;

мы можем выполнить процедуру, которая действует как триггер выбора или триггер соединения. Эта процедура может быть написана таким образом, что она, например, будет отвергать подключения в некоторые часы дня или протоколировать время, когда пользователи пытаются подключиться к базе данных.

Мы можем протоколировать только имена известных пользователей — т. е. только тех пользователей, имена которых уже хранятся в таблице USERS — и не существует возможности сообщить, было ли подключение успешным. Однако даже такая ограниченная информация, которую мы можем внести в протокол, является полезной. Это может проинформировать нас о попытках подключения в необычное время, что позволит обнаружить множество подозрительных подключений за короткий промежуток времени.

Для подобной реализации нам нужна таблица для протокола и хранимая процедура для выполнения работы.

Таблица протокола

Таблица протокола должна быть внешней таблицей, потому что транзакция, используемая сервером для идентификации пользователей, не подтверждается, а откатывается. Для внешних таблиц не выполняется отмена записанных данных при откате транзакции, как это происходит при добавлении данных в обычную таблицу.

CREATE TABLE,log_table

EXTERNAL FILE ‘C:Prograin FilesFirebirdFirebird_1_5security.log’ ( tstamp TIMESTAMP, uname CHAR(31) );

Если вы хотите, чтобы таблица протокола была читаема как текстовый файл, вы должны использовать CHAR(20) вместо TIMESTAMP, выполняя необходимые преобразования, и добавить еще два столбца: одиночный CHAR для разделения столбцов времени (tstamp) и имени (uname) и CHAR(2) для заполнения кодами возврата каретки и перевода строки.

Процедура подключения

Хранимая процедура имеет тип процедуры выбора, которую можно вызывать из просмотра. Если соединение успешное, происходит обращение к SUSPEND, и строка записывается в протокол. Если соединение ошибочное по той причине, что запрашиваемая из просмотра строка запрещена, то процедура просто завершается, не записав ничего в протокол. Выходной параметр является простой формальностью, его значение игнорируется.

CREATE PROCEDURE log_proc

(un VARCHAR(31)) RETURNS

(x CHAR(1) )

BEGIN

IF (USER = ») THEN

INSERT INTO log_table (TSTAMP, UNAME) VALUES ( CURRENT_HMESTAMP, :un);

/* и не забудьте изменить записанные поля, если вы изменили таблицу log_table, чтобы сделать ее текстовым файлом! */ IF (USER = » OR USER = ‘SYSDBA’ OR USER = :un) THEN SUSPEND;

END

Мы проверяем (USER = »), потому что, когда Firebird проверяет пароль, переменная USER пустая. Это помогает отличить, когда сервер проверяет пароль, а когда пользователь напрямую соединяется с базой данных безопасности.

Реализация новой установки

Нам нужно удалить просмотр, который использовался в нашей реструктурированной базе данных безопасности, и создать новую версию, которая вызывает хранимую процедуру:

CREATE VIEW USERS (USER_NAME) AS SELECT * FROM users2

WHERE EXISTS (SELECT * FROM logjproc(users2.user_name));

He забудьте восстановить полномочия, которые были потеряны при удалении просмотра:

GRANT SELECT ON USERS TO PUBLIC;

GRANT UPDATE (PASSWD, GROUP_NAME, UID, GID, FIRST_NAME, MIDDLE_NAME, LAST_NAME) ON USERS TO PUBLIC;

Нужно добавить несколько новых полномочий, связанных с хранимой процедурой:

GRANT INSERT ON log_table TO PROCEDURE log_proc; GRANT EXECUTE

ON PROCEDURE log_proc TO PUBLIC;

Поскольку записи протокола посотянно добавляются в log_table, будет нужно удалять или переименовывать внешний файл время от времени. База данных безопасности и, следовательно, внешний файл освобождаются после завершения идентификации пользователя, так что переименование файла не должно вызвать проблем.

Как остановить злоумышленников

Поскольку мы способны протоколировать имена пользователей, которые пытались подключиться к базе данных, и время этих попыток, мы можем использовать эту информацию для дальнейшего ограничения доступа.

Например, можно подсчитать количество попыток подключений конкретного пользователя в течение последней минуты и, если это количество достигает некоторого

предела, блокировать соединение для данного имени пользователя. Это позволит нам установить некоторую защиту против грубых атак, когда кто-то пытается проникнуть в базу данных, многократно сканируя возможные пароли. Мы можем установить временную блокировку для любого имени пользователя, чье поведение похоже на атаку.

Интервал времени и ограничение на количество подключений должны выбираться аккуратно, чтобы остановить злоумышленников, а не наказать добросовестного пользователя, который просто плохо набирает текст. Open VMS использует похожий подход.

Соответствующий фрагмент кода хранимой процедуры выглядит следующим образом:

. . .

DECLARE VARIABLE Cnt INTEGER;

SELECT COUNT(*)

FROM log_table

WHERE uname = :un

AND tstamp > CURRENT_TIMESTAMP — 0.0007

INTO :cnt;

IF (cnt >= 3) THEN EXIT;

Вы можете изменять константы, а именно 3 (допустимое количество ошибок) и 0.0007 (интервал, приблизительно равный одной минуте). Эта процедура действует для всех пользователей.

Одной из возможных модификаций может быть выбор одного пользователя, не являющегося SYSDBA (не SYSDBA, потому что пользователь SYSDBA, скорее всего, и будет выбран для атак), и исключение его из блокирующей процедуры. Сделайте этого пользователя владельцем всех баз данных, наделив его правами на выполнение останова базы данных.

Пора дальше

Ясно, что безопасность на уровне сервера в Firebird имеет недостатки. В следующей главе обсуждается поддержка в Firebird полномочий SQL, которые могут быть реализованы для всех баз данных. Применение полномочий SQL запутанно, однако при аккуратном использовании они предоставляют основной внутренний уровень безопасности данных баз данных в системах, которые адекватно защищены от краж.

ГЛАВА 35. Безопасность на уровне базы данных.

Безопасность на уровне базы данных в Firebird решает две задачи: во-первых, не разрешить доступ пользователей, идентифицированных на сервере, к данным в вашей базе данных, и, во-вторых, предоставить доступ пользователям, которые работают с вашей базой данных. Средствами реализации такой безопасности на уровне базы данных являются привилегии SQL.

Первая цель, блокирование ненужных пользователей, авторизованных на сервере, используется в средах, где базы данных, которыми владеют многие объекты, запущены на одном сервере — обычно, на сайте, где выполняются сервисы для множества заказчиков. В подобных ситуациях заказчики провайдера обычно не имеют доступа SYSDBA.

Вторая цель требует большой работы по ограничению доступа к конфиденциальным или чувствительным данным. Привилегии SQL могут поддерживать любой уровень детализации доступа к любому элементу данных вплоть до уровня столбца.

В отличие от пользователей (как обсуждалось в главе 34) привилегии применимы к уровню базы данных и хранятся непосредственно в самой базе данных в системной

таблице RDB$USER_PRIVILEGES.

Безопасность и доступ по умолчанию

База данных и все ее объекты (таблицы, просмотры и хранимые процедуры) становятся защищенными от неавторизованного доступа в момент их создания. То есть доступ является «необязательным». Ни один пользователь не может получить доступ к любому объекту базы данных, не получив на это полномочий. За исключением пользователей с особыми привилегиями — владелец, SYSDBA и (в POSIX) Суперпользователь — пользователи должны иметь привилегии SQL к любой операции, даже к SELECT.

А теперь плохие новости

Существует большая загвоздка, так что не будьте так легко внушаемы ложным чувством безопасности. Несуществующие объекты не являются защищенными. Любой пользователь, имеющий доступ к базе данных, может создать любой допустимый объект базы данных — включая объявления внешних функций и таблиц, связанных с внешними таблицами — которые потенциально могут быть использованы в комбинации с установкой и выполнением хакерского кода на сервере.

С возможностью при инсталляции Firebird 1.5 ограничивать местоположение внешних объектов, к которым может обращаться сервер, ситуация несколько улучшается. При этом риски не устраняются полностью- вы должны выполнить конкретные шаги по реализации этой возможности и созданию ограничений файловой системы операционной системы. Доступ по умолчанию к внешним файлам в инсталляторе установлен в NONE, и каталоги внешних функций ограничены деревом UDF. Ваша задача — позаботиться о системных ограничениях.

Системные таблицы, где Firebird хранит все метаданные, включая сами привилегии SQL, вовсе не защищены привилегиями SQL.

Совет, как наказать идиотов-пользователей и плохих парней

Мой уважаемый коллега Павел Цизар (Pavel Cisar) предложил прием устранения недостатка привилегий SQL по защите метаданных Firebird, когда идиоты- пользователи, минуя DDL, пытаются изменять метаданные в системных таблицах, внося в них беспорядок. Это также отражает злонамеренные попытки разрушить ваши метаданные с помощью скрипта. Вот данное решение.

Хотя кажется, что PUBLIC (т. е. все) имеют доступ ALL К системным таблицам, тем не менее существует таинственный черный ход в управлении правами SQL, который может легко исправить ситуацию. Вы можете ограничить доступ к системным таблицам, так же, как и к любым другим таблицам базы данных, предоставив, а затем отменив полномочия. При этом права предоставляются только для того, чтобы быть отмененными.

Все, что нужно сделать, — это просто установить управление доступом к системным таблицам путем выполнения серии операторов GRANT ALL <системная таблица> то PUBLIC. После этого мы можем отменить любые права.

Я не знаю точного технического объяснения, каким именно образом это работает, но это мой совет. Оператор GRANT создает управляющий список доступа (Access Control List, ACL) для системной таблицы, который проверяется в коде. Какая-то ветвь в этом коде означает «предоставить всем все привилегии, если элемент ACL не найден для системной таблицы, иначе использовать ACL».

Следует помнить некоторые вещи.

• Эта установка не сохраняется после восстановления базы данных из резервной копии, следовательно, напишите скрипт, который вы будете использовать каждый раз для только что восстановленной базы данных.

• Вам нужно быть внимательным по поводу удаления прав SELECT у PUBLIC К некоторым системным таблицам, потому что функции API isc_biob_iookup_desc() и isc_array_iookup_bounds() зависят от этой возможности. От этого также могут зависеть некоторые инструментальные средства и библиотеки.

• Удаление прав записи в системные таблицы не ограничивает возможность их изменения обычным нормальным способом с использованием команд DDL. Предотвращается только бесполезная прямая корректировка системных таблиц.

Привилегия дает возможность пользователю иметь некий вид доступа к объекту в базе данных. Она предоставляется с помощью оператора GRANT и убирается с использованием оператора REVOKE.

Синтаксис разрешения доступа:

GRANT <привилегия> ON <объект>

ТО <пользователь>;

привилегия, предоставленная пользователю к объекту, создает разрешение. Синтаксис для удаления разрешений:

REVOKE <привилегия> ON <объект>

FROM <пользователь>;

Доступны некоторые варианты «центрального» синтаксиса. Мы рассмотрим их несколько позже.

Привилегии

Привилегия представляет разрешение выполнять операцию DML. В табл. 35.1 описываются привилегии SQL, которые могут быть предоставлены или удалены.

Таблица 35.1. Привилегии SQL

Привилегия	Доступ
SELECT	Чтение данных
INSERT	Создание новых строк
UPDATE	Изменение существующих данных
DELETE	Удаление строк
REFERENCES	Ссылка на первичный ключ из внешнего ключа. Это всегда необходимо делать при предоставлении привилегий к таблицам, содержащим внешние ключи
ALL	Выборка, добавление, изменение, удаление и ссылка на первичный ключ из внешнего ключа
EXECUTE	Выполнение хранимой процедуры или вызов ее с использованием SELECT. Эта привилегия никогда не предоставляется как часть привилегии ALL (см. разд. «Ключевое слово ALL»)
ROLE	Предоставляет все привилегии, назначенные роли. Если роль существует и имеет назначенные ей привилегии, она становится привилегией, которая может явно назначаться пользователям. Роль никогда не предоставляется как часть привилегии ALL

Упаковка привилегий

SQL Firebird реализует возможности упаковки множества привилегий для назначения индивидуальным получателям, спискам или специально сгруппированным пользователям. Это пакет ALL, разделенные запятыми списки и роли SQL.

Ключевое слово ALL

Ключевое слово ALL упаковывает привилегии SELECT, INSERT, UPDATE, DELETE и REFERENCES в одном назначении. Роли и привилегия EXECUTE не включены в пакет ALL.

Списки привилегий

Привилегии SELECT, INSERT, UPDATE, DELETE и REFERENCES также могут быть предоставлены или отменены поодиночке или в списках, разделенных запятыми. При этом в операторах, где предоставляются или отменяются привилегия EXECUTE или привилегия роли, нельзя предоставлять или отменять другие привилегии.

Роли

Роль создается в базе данных и доступна только в этой базе данных. Думайте о роли, как о емкости для набора привилегий. Когда емкость «заполнена» некоторыми привилегиями, она становится доступна — как привилегия — некоторым типам пользователей.

Может быть создано множество ролей. Здесь основная мысль в том, чтобы упаковать и управлять дискретными наборами привилегий, которые могут назначаться и отменяться как одно целое, вместо того, чтобы постоянно назначать и отменять большие количества индивидуальных привилегий.

Роль никогда не может быть предоставлена как часть пакета ALL, хотя роли могут быть назначены привилегии ALL.

Роли не являются группами

Роли не похожи на пользовательские группы операционной системы. Пользователю Firebird может быть назначено более одной роли, однако он может подключиться к базе данных за один раз только с одной ролью.

Группы UNIX

Firebird поддерживает группы UNIX на платформах POSIX. Если реализована идентификация на уровне системы, вы можете предоставлять привилегии группам UNIX. См. вариант то GROUP <mix-rpynna> в операторах GRANT и REVOKE.

Объекты

«Другой частью» полномочий является объект, к которому применяется привилегия или для которого она отменяется. Объектом может быть таблица, просмотр, хранимая процедура или роль, хотя не все привилегии применимы ко всем типам объектов. Например, привилегия UPDATE неприменима к процедуре, а привилегия EXECUTE — к таблице или просмотру.

Не существует «пакета объектов», который включает все или группу объектов. Должен быть, по крайней мере, один оператор GRANT для каждого объекта базы данных.

Ограничения привилегий

Привилегии SELECT, INSERT, UPDATE и DELETE применимы только к объектам, являющимся таблицами или просмотрами, REFERENCES применяется только к таблицам — точнее к тем, на которые ссылаются внешние ключи.

В случае просмотров пользователь должен иметь привилегии к самому просмотру, однако и полномочия к базовым таблицам должны быть предоставлены так или иначе. Правило гласит, что для владельца просмотра, для самого просмотра или для пользователя просмотра должны быть предоставлены соответствующие привилегии к базовым таблицам. Не имеет значения, как были получены привилегии, однако одно из трех должно быть выполнено.

Естественно изменяемые просмотры также требуют полномочий SELECT, INSERT, UPDATE и DELETE к базовым таблицам. Если просмотры только для чтения становятся изменяемыми с помощью триггеров, то триггерам нужны полномочия к базовым таблицам в соответствии с операциями, определенными в событиях триггера.

! ! !

ПРИМЕЧАНИЕ. Для создания просмотра необходимо иметь полномочия SELECT К базовым таблицам. В тех редких случаях, когда любая из этих.привилегий SELECT отменяется после создания просмотра, она должна быть добавлена для самого просмотра или для пользователей этого просмотра.

. ! .

EXECUTE может применяться только для хранимых процедур. Роли никогда не предоставляются «для» какого-либо объекта.

Пользователи

Пользователи являются получателями полномочий; они теряют их, когда полномочия отменяются. Пользователь может быть пользователем, определенным в базе данных безопасности, учетной записью или группой UNIX, специальным пользователем или объектом базы данных.

* Роли в качестве пользователей: когда роли назначены привилегии, она становится пользователем. Когда роль получает требуемые привилегии к объектам, она изменяет свой статус и становится привилегией, которая может быть предоставлена некоторым другим типам пользователей. Когда происходит подключение к базе данных под этой ролью, такие пользователи получают все привилегии, которые были предоставлены этой роли.

* Просмотры в качестве пользователей: просмотрам нужны полномочия для доступа к таблицам, другим просмотрам и к хранимым процедурам.

* Процедуры и триггеры в качестве пользователей:

хранимой процедуре, которая обращается к таблицам и просмотрам и выполняет другие процедуры, нужны полномочия к этим объектам. Триггеру, который выполняет процедуры, нужны к ним полномочия, а также к любым таблицам и просмотрам, к которым он обращается, отличным от той таблицы, которой он принадлежит.

Специальные пользователи

Пользователь SYSDBA имеет особые права ко всем базам данных и их объектам, независимо от того, какой пользователь ими владеет^[137]. Более того, в операционных системах, где реализована концепция Суперпользователя, — пользователь с привилегиями root или locksmith, — такой пользователь также имеет полный доступ и деструктивные права ко всем базам данных и их объектам, если он соединяется под этим идентификатором. Подробности см. в разд. «Слабое место POSIX» главы 34.

Вначале создатель объекта, его владелец, является единственным пользователем, кроме SYSDBA и Суперпользователя, который имеет доступ к этому объекту (таблице, просмотру, хранимой процедуре или роли) и может позволять получать к нему доступ другим пользователям. Любой пользователь затем может запустить «цепочку» полномочий, предоставляя другим пользователям права назначать привилегии. Такое право может передаваться добавлением предложения WITH GRANT OPTION К полномочиям.

Похожим образом SYSDBA или владелец роли может уточнять привилегию роли, передавая ее пользователю как WITH ADMIN OPTION. При этом предполагается, что пользователь, который подключается с этой ролью, не наследует от роли права WITH GRANT OPTION. Подробности этого далее.

Пользователь PUBLIC

PUBLIC является пользователем, который обозначает всех пользователей в базе данных безопасности. Он не включает в себя хранимые процедуры, триггеры, просмотры или роли.

Если множество баз данных выполняется на одном сервере, предоставление больших пакетов привилегий может сохранить много времени на набор текста, однако они же могут легко по ошибке предоставить привилегии пользователям, которые не должны их иметь.

Встроенные серверы

Настоятельно рекомендуется, чтобы базы данных, предназначенные для использования во встроенном сервере, были жестко защищены полномочиями. Пользователь встроенного сервера под Windows намеренно не идентифицируется, следовательно, не существует базы данных безопасности! Коль скоро не выполняется проверка пользователей по операторам GRANT, ТО операторы полномочий могут быть применены к «фальшивому пользователю» (т. е. вымышленное имя, которое использует ваше приложение для соединения с базой данных через встроенный сервер).

Предоставление привилегий

Привилегии доступа могут быть предоставлены к целой таблице или просмотру. Можно также ограничить привилегии UPDATE и REFERENCES указанными столбцами.

Оператор GRANT используется для предоставления пользователю, роли или хранимой процедуре конкретной привилегии к объекту. Общий синтаксис для предоставления привилегий к объектам:

GRANT <привилегии>

ON [TABLE] <таблица> | <просмотр> [ <объект> <опустить предложение ON> ТО <типичный-пользователь>

[{WITH GRANT OPTION} | {WITH ADMIN OPTION}];

<привилегии> = <привилегия> | <список-привилегий> | <имя-роли> ( ALL

<привилегия> = INSERT | DELETE | UPDATE [(столбец [, столбец [,..]] ) ]

| REFERENCES [(столбец [, столбец [,..]] ) ] | EXECUTE

<список-привилегий> = [, привилегия [, <список-привилегий> [,…]]]

Обратите внимание, что синтаксис для привилегии включает возможность ограничения UPDATE или REFERENCES отдельными столбцами, как обсуждается в следующем разделе.

<объект> = <хранимая-процедура> | <роль-с-привилегиями>

<типичный-пользователь> — <пользователь> | PUBLIC |

<список-пользователей> | <UNIX-пользователь> |

GROUP <UNIX-rpynna> | <пользователь-объект>

<список-пользователей> = <пользователь>,

{<пользователь> | <список-пользователей>}

<пользователь-объект> — <роль> | <триггер> | <хранимая-процедура>

Здесь пользователь- обычно пользователь, определенный в таблице USERS В базе данных безопасности Firebird. Во всех сетях клиент-сервер в POSIX это также может быть учетная запись пользователя, которая находится в /etc/password на серверной и клиентской машине, или группа UNIX, находящаяся на обеих машинах в /etc/group. Для баз данных, используемых во встроенном сервере под Windows, допустим «фальшивый пользователь» (известный приложению).

Следующий оператор предоставляет некоторые привилегии к таблице DEPARTMENTS пользователю CHALKY:

GRANT SELECT, UPDATE, INSERT, DELETE ON DEPARTMENTS TO CHALKY;

Права UPDATE к столбцам

Привилегия UPDATE, будучи неизмененной, позволяет пользователю изменять любой столбец таблицы. Однако если вы зададите список столбцов, разделенных запятыми, пользователь будет ограничен в изменении только указанными столбцами.

В следующем операторе все пользователи будут иметь полномочия на изменение для таблицы CUSTOMER, однако они смогут изменять только столбцы CONTACT FIRST,

CONTACT_LAST и PHONE_NO:

GRANT UPDATE (CONTACT_FIRST, CONTACT_LAST, PHONE_NO) ON CUSTOMER TO PUBLIC;

* Когда при предоставлении привилегии UPDATE используется список столбцов, множество полномочий сохраняется в системной таблице RDB$USER_PRIVILEGES, по одному для каждого столбца. Права могут предоставляться или отменяться для каждого столбца индивидуально^[138].

* Когда не используются полномочия на уровне столбца, создается только одно разрешение. Нет способа удалить права к одним столбцам и сохранить для других. Нужно будет отменить разрешения, содержащие права, которые вы хотите отменить, и добавить новые с исправленными правами.

Спасибо правилам привилегий SQL — «самая забавная штука от Marx Brothers», по словам коллеги — можно предоставлять как на уровне столбца, так и на уровне таблицы привилегии UPDATE и REFERENCES одному и тому же пользователю. Это может привести к путанице, если права пользователя на уровне столбца UPDATE или REFERENCES отменяются, а те же полномочия пользователя на уровне таблицы сохраняются.

Просмотры предоставляют элегантный способ ограничения доступа к таблицам, ограничивая столбцы и/или строки, которые видимы пользователю, позволяя при этом выполнить любые настройки. Эта тема обсуждалась в главе 24.

Права REFERENCES к столбцам

Привилегия REFERENCES является необходимым дополнением при предоставлении полномочий к таблице, у которой есть внешний ключ. Она нужна, если пользователь, создающий внешний ключ в таблице, не владеет таблицей, на которую ссылается этот ключ.

REFERENCES предоставляет полномочия к столбцам. Должны быть включены все столбцы, на которые ссылается внешний ключ таблицы, к которой предоставляются права. Если оператор GRANT REFERENCES ссылается на таблицу без указания столбцов, то полномочия предоставляются к каждому столбцу. Столбцы, которые не указаны в связи между внешним ключом и первичным ключом главной таблицы, не включаются в привилегию.

Вы можете задать только ключевые столбцы и, возможно, сохранить некоторую избыточность, если первичная таблица содержит очень много столбцов. Если вы сделаете так, вы должны задать все связанные ключевые столбцы. Упрощенный синтаксис выглядит так:

GRANT REFERENCES

ON <первичная-таблица> [ (<ключевой-столбец>

[, <ключевой-столбец> [, . . . ] ] ) ]

ТО <пользователь>

[WITH GRANT OPTION] ;

Следующий пример предоставляет привилегии REFERENCES К таблице DEPARTMENTS пользователю CHALKY, позволяя CHALKY записывать внешний ключ, который ссылается на первичный ключ таблицы DEPARTMENTS, даже если он не владеет этой таблицей:

GRANT REFERENCES ON DEPARTMENTS (DEPT_NO) TO CHALKY;

! ! !

СОВЕТ. Если видимость ключей не является проблемой, предоставьте привилегии REFERENCES для PUBLIC

. ! .

Привилегии к объектам

Когда для триггера, хранимой процедуры или просмотра нужен доступ к таблице или просмотру, достаточно, чтобы владелец объекта, к которому требуется доступ, сам объект или пользователь, использующий триггер, процедуру или просмотр, имел необходимые полномочия.

С другой стороны, привилегии к таблице могут быть предоставлены процедуре, а не индивидуальным пользователям для повышения безопасности. Пользователю нужна только привилегия EXECUTE к процедуре, которая осуществляет доступ к таблице.

Хранимой процедуре, просмотру или триггеру иногда нужны привилегии для доступа к таблице или просмотру, которые имеют другого владельца. Для предоставления привилегий триггеру или хранимой процедуре включите соответствующее ключевое слово TRIGGER или PROCEDURE перед именем модуля.

В следующем примере процедуре COUNT_CHICKENS предоставляются полномочия INSERT к таблице PROJ_DEPT_BUDGET:

GRANTINSERTON PROJ_DEPT_BUDGETTO PROCEDURE COUNT_CHICKENS;

Предоставление привилегии EXECUTE

Для использования хранимой процедуры пользователям, триггерам или другим хранимым процедурам нужна к ней привилегия EXECUTE. ЕСЛИ просмотр выбирает выходные поля из хранимой процедуры выбора, просмотр должен иметь привилегию

EXECUTE, а не привилегию SELECT.

Упрощенный синтаксис выглядит следующим образом:

GRANT EXECUTE

ON PROCEDURE <имя-процедуры> TO <получатель>;

<получатель> = [ PROCEDURE <имя-процедуры> [, <имя-процедуры> [, ..]]] [ TRIGGER <имя-триггера> [, <имя-триггера> [, …]]] [ VIEW <имя-просмотра> [, <имя-просмотра> [, …]]] | <имя-роли> | <пользователь-или-список> | PUBLIC [WITH GRANT OPTION];

Хранимой процедуре или триггеру нужна привилегия EXECUTE К хранимой процедуре, если она имеет другого владельца. Помните, что владельцем триггера является пользователь, создавший таблицу.

Если ваш оператор GRANT EXECUTE предоставляет привилегии для PUBLIC, то никакие другие типы получателей привилегий не могут быть представлены в качестве аргументов то.

В следующем примере оператор GRANT EXECUTE предоставляет привилегию к процедуре CALCULATE_BEANS двум обычным пользователям FLAT FOOT и KILROY и Двум Хранимым процедурам, чьи владельцы не являются владельцами CALCULATE_BEANS:

GRANT EXECUTE ON PROCEDURE CALCULATE_BEANS

TO FLATFOOT,

KILROY,

PROCEDURE DO_STUFF, ABANDON_OLD ;

Привилегии к просмотрам

Привилегии к просмотрам являются довольно запутанными. Владелец просмотра должен предоставить пользователям привилегию SELECT, как это сделал бы владелец таблицы. Сложности начинаются, если просмотр является изменяемым — естественным образом или через триггеры просмотра- или если просмотр включает другие просмотры или хранимые процедуры выбора. Изменения данных изменяемого просмотра фактически выполняют изменения в базовых таблицах. Если владельцы базовых объектов еще не предоставили пользователю соответствующих прав (INSERT, UPDATE, DELETE, EXECUTE) к базовым таблицам и объектам, а также к хранимым процедурам выбора или к просмотрам, то пользователю нужно их получить от владельца просмотра.

Привилегии REFERENCES неприменимы к просмотрам за исключением одной (обычно опускаемой) ситуации. Если просмотр использует таблицу, которая имеет внешние ключи, ссылающиеся на другие таблицы, то просмотру нужны привилегии REFERENCES к этим другим таблицам, если эти таблицы сами не используются в данном просмотре.

Подробности см. в разд. «Привилегии» главы 24.

Множество привилегий и множество получателей привилегий

Есть возможность предоставлять несколько привилегий в одном операторе и предоставлять одну или более привилегий множеству пользователей или объектов.

Множество привилегий

Для предоставления получателю нескольких привилегий к таблице перечислите предоставляемые привилегии в списке, отделяя друг от друга запятыми. Следующий оператор назначает полномочия INSERT и UPDATE К таблице DEPARTMENT пользователю

CHALKY:

GRANT INSERT, UPDATE ON DEPARTMENT TO CHALKY;

Список привилегий может быть любой комбинацией в любом порядке привилегий

SELECT, INSERT, UPDATE, DELETE и REFERENCES. Привилегия EXECUTE должна назначаться в отдельном операторе.

Привилегия REFERENCES не может быть назначена просмотру.

Привилегия ALL

Привилегия ALL объединяет привилегии SELECT, INSERT, UPDATE, DELETE и REFERENCES В одном пакете. Например, следующий оператор предоставляет CHALKY полный пакет полномочий к таблице DEPARTMENT:

GRANT ALL ON DEPARTMENT TO CHALKY;

Вы также можете назначать пакет ALL триггерам и процедурам. В следующем операторе процедура COUNT_CHICKENS получает полные права к таблице PROJ_DEPT_BUDGET:

GRANT ALL ON PROJ_DEPT_BUDGET TO PROCEDURE COUNT_CHICKENS;

Привилегии для множества пользователей

Несколько видов синтаксиса позволяют вам предоставлять привилегии множеству пользователей в одном операторе. Вы также можете назначать привилегии:

* списку именованных пользователей или процедур;

* группе UNIX;

* всем пользователям (PUBLIC);

* роли (затем назначая эту роль списку пользователей, PUBLIC или группе UNIX).

Список именованных пользователей

Для назначения одних и тех же привилегий доступа пользователям в одном операторе запищите список пользователей, разделенных запятыми, на месте одного имени пользователя.

Следующий оператор предоставляет полномочия INSERT и UPDATE К таблице DEPARTMENT пользователям MICKEY, DONALD и HPOTTER:

GRANT INSERT, UPDATE ON DEPARTMENTS TO MICKEY, DONALD, HPOTTER;

Список процедур

Для назначения привилегий нескольким процедурам в одном операторе запишите список процедур, разделенных запятыми. Здесь две процедуры получают привилегии в одном операторе:

GRANT INSERT, UPDATE ON PROJ_DEPT_BUDGET

TO PROCEDURE CALCULATE_ODDS, COUNT_BEANS;

Группа UNIX

Имена учетных записей операционной системы Linux/UNIX доступны для безопасности в Firebird через привилегии Firebird, которые не являются стандартом SQL. Клиент, выполняющийся как пользователь UNIX, применяет этот идентификатор пользователя в базе данных, даже если такая учетная запись не определена в базе данных безопасности Firebird.

Машина, получающая доступ к серверу, должна быть в списке доверенных машин на сервере (файлы /etc/host.equiv или /etc/gds_host.equiv, или в .rhost в домашнем каталоге пользователя на сервере). При соединении пользователь использует идентификацию его группы, если он не предоставил для Firebird свое имя пользователя и пароль в качестве параметров соединения — учетные записи Firebird перекрывают учетные записи UNIX.

Группы Linux/UNIX совместно используют такое поведение: пользователь SYSDBA или Суперпользователь могут назначать привилегии SQL группам UNIX. Любая операция над учетной записью на уровне системы, которая является членом группы, наследует привилегии, предоставленные группе, например:

GRANT ALL ON CUSTOMER TO GROUP sales;

Все пользователи (PUBLIC)

Для назначения одних и тех же привилегий доступа к таблице всем пользователям предоставьте привилегии PUBLIC, PUBLIC только пользователей — не триггеры, процедуры, просмотры или роли.

GRANT SELECT, INSERT, UPDATE ON DEPARTMENT TO PUBLIC;

Привилегии, предоставленные пользователям с помощью PUBLIC, могут быть отменены только путем отмены их у PUBLIC. Вы не можете, например, отменить привилегию у CHALKY, которую CHALKY получил как член PUBLIC.

Привилегии через роли

Процесс реализации ролей состоит из четырех шагов:

1. Создание роли с использованием оператора CREATE ROLE.

2. Назначение привилегий этой роли посредством GRANT привилегия то роль.

3. Назначение роли пользователям посредством GRANT роль то пользователь.

4. Задание роли вместе с именем пользователя при соединении с базой данных.

Создание роли

Синтаксис создания роли прост:

CREATE ROLE <имя-роли>;

Пользователь SYSDBA или владелец базы может создавать роли, предоставлять им привилегии и передавать эти «нагруженные» роли пользователям. Если роль предоставлена с параметром WITH ADMIN OPTION, получатель этой роли может предоставлять ее другим пользователям с WITH ADMIN OPTION или без.

Назначение привилегий роли

Для «загрузки» роли привилегиями просто предоставьте ей требуемые привилегии, как если бы роль была обычным пользователем:

GRANT <привилегии> ТО <имя-роли>;

Предоставление роли пользователям

В операторе GRANT для предоставления роли пользователям опускается предложение ON- здесь неявно используются полномочия, «загруженные» в роль.

GRANT <имя-роли> [, <имя-роли> [, …]]

TO [DSER] <имя-пользователя> [, [OSER] <имя-пользователя> [, …]] [WITH ADMIN OPTION];

Необязательное предложение WITH ADMIN OPTION позволяет получающему роль предоставлять эту роль другим пользователям, а также отменять ее. Это работает таким же образом, что и WITH GRANT OPTION для обычных полномочий — см. разд. «Предоставление прав на предоставление привилегий».

Следующий пример создает роль MAITRE D, предоставляет этой роли привилегии ALL К таблице DEPARTMENT, а затем предоставляет роль пользователю HORTENSE. Это дает пользователю HORTENSE привилегии SELECT, INSERT, UPDATE, DELETE и REFERENCES К таблице DEPARTMENT.

CREATE ROLE MAITRE_D;

COMMIT;

GRANT ALL

ON DEPARTMENT

TO MAITRE_D;

GRANT MAITRE_D TO HORTENSE;

Подключение к базе данных с использованием роли

При соединении включите ROLE в список параметров соединения и укажите ту роль, чьи привилегии вы хотите использовать в этом соединении. Это будет работать, только если данному пользователю была предоставлена указанная роль:

CONNECT <путь-к-базе-данных>

USER <ваше-имя-пользователя>

ROLE <имя-роли>

PASSWORD <ваш-пароль>;

Удаление роли

Если вы удаляете роль, то все привилегии, предоставленные этой роли, отменяются. Чтобы удалить роль MAITRE_D, выполните:

DROP ROLE MAITRE D;

! ! !

ПРИМЕЧАНИЕ. Если вам нужно лишь удалить привилегии, предоставленные пользователю с помощью роли, или удалить привилегии роли, используйте оператор REVOKE (см. разд. «Отмена полномочий»).

. ! .

Предоставление прав на предоставление привилегий

Вначале только владелец таблицы или просмотра или пользователь SYSDBA могут предоставлять полномочия к этому объекту другим пользователям. Добавьте WITH GRANT OPTION в конец оператора GRANT для передачи пользователю права предоставлять привилегии вместе с самими привилегиями.

Следующий оператор назначает полномочия SELECT пользователю HPOTTER и дает право HPOTTER предоставлять полномочия SELECT другим:

GRANT SELECT ON DEPARTMENT TO HPOTTER WITH GRANT OPTION;

WITH GRANT OPTION не может назначаться триггерам или процедурам.

Права WITH GRANT OPTION являются кумулятивными, даже если передаются различными пользователями. Например, HPOTTER может получить право предоставлять права SELECT к таблице DEPARTMENT от одного пользователя и INSERT К DEPARTMENT от другого.

В следующем примере HPOTTER имеет доступ SELECT К таблице DEPARTMENT с правом передавать полномочия, HPOTTER может предоставлять полномочия SELECT другим пользователям. Предположим, HPOTTER теперь также получает полномочия INSERT к этой же таблице, но без права предоставлять эти полномочия:

GRANT INSERT ON DEPARTMENT TO HPOTTER;

Пользователь HPOTTER может выбирать данные и добавлять данные в таблицу DEPARTMENT. Он может предоставлять полномочия SELECT к таблице DEPARTMENT, но не может назначать полномочия INSERT, потому что он не имеет права предоставлять эту привилегию.

Существующие привилегии пользователя могут быть расширены включением права предоставлять привилегии. Для этого нужно выдать второй оператор GRANT для той же привилегии, который будет включать предложение WITH GRANT OPTION.

Для предоставления пользователю HPOTTER права предоставлять полномочия INSERT К таблице DEPARTMENT просто выполните новый оператор:

GRANT INSERT ON DEPARTMENT TO HPOTTER WITH GRANT OPTION;

Подводя итог, скажем, что пользователь может предоставлять привилегии доступа (SELECT, INSERT, UPDATE, DELETE и REFERENCES) К объекту другим пользователям или объектам, если пользователь:

* владеет этим объектом;

* получил такую привилегию к этому объекту вместе с WITH GRANT OPTION;

* получил эту привилегию путем предоставления ему роли, содержащей привилегию вместе с WITH ADMIN OPTION.

SQL допускает операторы GRANT, которые предоставляют пользователю дубликаты полномочий.

Неожиданные эффекты

SQL позволяет.одному и тому же получателю прав получать одни и те же полномочия из различных источников, даже если предоставляемые права уже есть у получателя. Каждый раз, когда один пользователь расширяет у другого пользователя права передавать полномочия, он открывает еще один источник, из которого любой пользователь может получить полномочия. Структура полномочий потенциально может стать пресловутым «птичьим гнездом», из которого очень трудно вытащить фактическое состояние полномочий индивидуального пользователя или объекта.

Предположим, у нас есть два пользователя, SERENA и HPOTTER, с соответствующими привилегиями и правами предоставлять другим полномочия. Оба выдали следующий оператор:

GRAN TINSERT

ON DEPARTMENT

TO BRUNHILDE

WITH GRANT OPTION;

Позднее SERENA отменяет привилегию и право предоставлять полномочия у BRUNHILDE:

REVOKE INSERT

ON DEPARTMENT

FROM BRUNHILDE;

SERENA считает, что BRUNHILDE больше не имеет полномочий INSERT и не может предоставлять другим права к таблице DEPARTMENT. Однако выполненный оператор REVOKE не имеет эффекта, поскольку BRUNHILDE все еще имеет полномочия INSERT и право предоставлять привилегии, полученные от HPOTTER.

Так как количество пользователей с привилегиями и возможностью предоставлять другим права растет, вероятно, что различные пользователи могут предоставлять одни и те же привилегии и возможность предоставлять другим права одному пользователю. Довольно просто, как и ядерное деление, это может выйти из-под контроля. Отмена какого-либо полномочия может оказаться большой работой. Отмена всех (или многих) полномочий у одного конкретного пользователя может оказаться астрономически сложной проблемой.

Если у пользователя была возможность получать права от различных пользователей, существует два возможных решения, оба не очень приятных.

* Найдите каждое право, предоставленное этому пользователю, вместе с тем, кто предоставлял это право, и заставьте всех отменить каждое предоставленное право. Это станет весьма запутанным, если использовались варианты ALL и PUBLIC, потому что отмена более целенаправленного права не отменяет прав, предоставленных через ALL, PUBLIC, роли или группы.

* Владелец каждой таблицы и объекта (или SYSDBA) выполняет операторы REVOKE, действующие на всех пользователей этой таблицы, а затем выдает операторы GRANT для установления привилегий только тем пользователям, кому нужно сохранить свои права.

Сервер не выдает никаких сообщений для команд REVOKE, независимо от того, была ли она успешна или ошибочна. Это будет тот самый момент вашей первой, неприятности, связанной с полномочиями SQL, когда вы возденете глаза к небесам и начнете размышлять о реальном назначении комитетов по стандартам на этой Земле. Хорошо спроектированная графическая утилита управления правами может сохранить вам рассудок. К счастью, многие программы администрирования осуществляют такую поддержку. Доступно множество инструментов управления полномочиями. (См. приложение 12.)

Более подробную информацию об отмене полномочий см. в следующем разделе.

! ! !

СОВЕТ. Хотя определение пользователей, ролей и назначение привилегий часто откладывается до момента, когда система готова к поставке пользователям, тем не менее создание схемы привилегий и соотнесение ее со списком пользователей нужно запланировать при проектировании системы. Поддержка диаграммы такой схемы является весьма полезным делом как при проектировании и тестировании системы, так и при ее документировании.

. ! .

Отмена полномочий

Оператор REVOKE требуется для удаления полномочий, назначенных операторами GRANT. Согласно стандарту, REVOKE должен каскадом отменить все привилегии, полученные всеми пользователями как результат WITH GRANT OPTION от данного пользователя. Однако вам не следует на это полагаться в Firebird, потому что конфликт правил стандарта при некоторых условиях может привести к логике реализации, отличной от предложенной в стандарте.

Операторы REVOKE могут отменить любую привилегию, которую может назначить оператор GRANT. Только пользователь SYSDBA или пользователь, предоставивший привилегию, могут отменить ее- те же самые или другие привилегии, предоставленные другими пользователями, не отменяются.

Полномочия, предоставленные «в куче», не могут отменяться индивидуально. Это означает:

* привилегия, которую пользователь получил в результате назначения ALL или в качестве роли, может быть отменена только предоставившим эту привилегию, путем отмены ALL или роли соответственно;

* отмена привилегии у пользователя, который получил ее путем PUBLIC или группы UNIX, может быть выполнена предоставившим эту привилегию путем отмены PUBLIC или группы соответственно;

* привилегии, предоставленные для PUBLIC, могут быть отменены только FROM PUBLIC.

Использование REVOKE

Упрощенный синтаксис для REVOKE внешне отличается от синтаксиса GRANT. Предложение ТО <получатель> заменяется на FROM <получатель?.

REVOKE <привилегии>

ON <объект>

FROM <получатель> ;

Следующий оператор отменяет привилегию SELECT К таблице DEPARTMENT у пользователя KILROY, если он получил ее при выполнении GRANT SELECT:

REVOKE SELECT ON DEPARTMENT FROM KILROY;

Следующий оператор отменяет привилегию UPDATE К таблице CUSTOMER для процедуры

COUNT_BEANS:

REVOKE UPDATE ON CUSTOMER FROM PROCEDURE COUNT_BEANS;

Следующий оператор удаляет привилегию EXECUTE, которая была предоставлена процедуре COUNT_BEANS К процедуре ABANDON_OLD:

REVOKE EXECUTE ON PROCEDURE ABANDON_OLD FROM PROCEDURE COUNT_BEANS;

Удаление множества привилегий

Для удаления нескольких, но не всех привилегий, предоставленных пользователю или процедуре, перечислите удаляемые привилегии, отделив их друг от друга запятыми. К примеру, следующий оператор удаляет привилегии INSERT и UPDATE к таблице DEPARTMENT у пользователя SERENA:

REVOKE INSERT, UPDATE ON DEPARTMENT FROM SERENA;

Следующий оператор удаляет две привилегии к таблице CUSTOMER у хранимой процедуры COUNT_BEANS:

REVOKE INSERT, DELETE

ON CUSTOMER

FROM PROCEDURE COUNT_BEANS;

Любая комбинация ранее назначенных привилегий SELECT, INSERT, UPDATE, DELETE или REFERENCES может быть отменена назначившим эти привилегии, неважно, были ли они назначены индивидуально, в списке или с использованием ALL.

Как и в случае GRANT, отмена привилегий REVOKE ALL объединяет привилегии SELECT, INSERT, UPDATE, DELETE и REFERENCES в одном выражении. Данный оператор отменит любое из этих назначенных полномочий.

Например, следующий оператор отменит все привилегии доступа к таблице

DEPARTMENTS у пользователя MAGPIE:

REVOKE ALL ON DEPARTMENTS FROM MAGPIE;

Если пользователь не имеет всех привилегий, включенных в ALL, оператор не вызовет исключения. Оператор REVOKE ALL может быть особенно полезным, если вы не знаете, какие привилегии имеет пользователь. Нет необходимости решать проблему устранения всех полномочий, доступных пользователю, потому что у REVOKE ALL есть ограничения на то, что он способен отменить.

Чего не отменяет REVOKE ALL

REVOKE ALL не отменяет:

* привилегии, наследуемые вместе с ролью;

* привилегии, полученные как PUBLIC;

* привилегии EXECUTE.

Отмена привилегии EXECUTE

Синтаксис отмены привилегии EXECUTE к хранимой процедуре:

REVOKE EXECUTE

ON PROCEDURE <имя-процедуры>

FROM <получатель> [, <получатель> [, …]]

| [TRIGGER <имя-триггера> [, <имя-триггера> [,…]]

[PROCEDURE <имя-процедуры> [, <имя-процедуры> [, …]]

[VIEW <имя-просмотра> [, VIEW <имя-просмотра> [, …]];

Следующий оператор удаляет привилегию EXECUTE у пользователя HPOTTER к процедуре COUNT_CHICKENS:

REVOKE EXECUTE ON PROCEDURE COUNT_CHICKENS FROM HPOTTER;

Отмена привилегий у нескольких пользователей

Теперь мы рассмотрим как получатели привилегий, указанные в предложении FROM оператора REVOKE, могут быть объединены для отмены привилегий.

Список пользователей

Используйте разделенный запятыми список пользователей для отмены привилегий у множества пользователей в одном операторе. Следующий оператор удаляет привилегии INSERT и UPDATE к таблице DEPARTMENTS у троих пользователей за один раз:

REVOKE INSERT, UPDATE

ON DEPARTMENTS

FROM MAGPIE, BRUNHILDE, KILROY;

Роль

Отмена привилегий, предоставленных роли, отменяет эти привилегии у всех пользователей, имеющих эту роль в качестве привилегий:

REVOKE UPDATE

ON DEPARTMENT

FROM CARTEBLANCHE;

Теперь пользователи, которым была назначена роль CARTEBLANCHE, больше не имеют привилегии UPDATE к таблице DEPARTMENT, но у них остаются другие привилегии (SELECT, INSERT, DELETE, REFERENCES, EXECUTE), которые они могли наследовать от

CARTEBLANCHE.

Вы можете использовать один оператор для отмены одних и тех же привилегий у одной или более ролей:

REVOKE DELETE, INSERT

ON DEPARTMENT

FROM CARTEBLANCHE, MAITRE_D;

Роль пользователя

Отмена назначенных роли пользователей отменяет у этих пользователей все полномочия, которые они получили с этой ролью. Используйте REVOKE для удаления роли, которую вы назначали пользователям. Следующий оператор отменяет роль

CARTEBLANCHE у пользователя KILROY:

REVOKE CARTEBLANCHE FROM KILROY;

KILROY больше не имеет привилегий доступа, полученных как результат его членства в этой роли. Однако это не оказывает влияния на других пользователей, которые получили эти привилегии через членство в данной роли.

Объекты

Для отмены привилегий у одной или более процедур, триггеров или просмотров включите соответствующее ключевое слово (PROCEDURE, TRIGGER, VIEW) перед именем объекта.

Вы можете отменить одну и ту же привилегию у различных типов объектов, задав разделенный запятыми список объектов каждого типа. В этом случае просто начните каждый список с ключевого слова типа объекта.

Следующий оператор удаляет привилегии INSERT и UPDATE К таблице CUSTOMER для двух процедур и триггера:

REVOKE INSERT, UPDATE

ON CUSTOMER

FROM PROCEDURE COUNT_CHICKENS, ABANDON_OLD

TRIGGER AI_SALES ;

Пользователь PUBLIC

Для отмены привилегий, которые все пользователи получили как пользователь PUBLIC, просто трактуйте PUBLIC, как и любого другого пользователя. Например, следующий оператор отменяет полномочия INSERT и DELETE К таблице DEPARTMENT у всех пользователей:

REVOKE SELECT, INSERT, UPDATE

ON DEPARTMENT

FROM PUBLIC;

После выполнения этого оператора привилегии INSERT и DELETE К таблице DEPARTMENT сохраняются у владельца этой таблицы и у пользователя SYSDBA, равно как и у имевших эти привилегии хранимых процедур, просмотров и триггеров. Отмена привилегий у PUBLIC также не убирает привилегии у пользователей, которые имеют их как собственные права.

Отмена права предоставлять привилегии

Для отмены права у пользователя предоставлять конкретную привилегию, но сохранить у него эту привилегию, используйте REVOKE GRANT OPTION:

REVOKE GRANT OPTION

FOR <привилегия> [, <привилегия> [,…]]

ON <таблица> | <объект>

FROM <пользователь> ;

Например, следующий оператор отменяет право предоставлять привилегию SELECT к таблице DEPARTMENT у пользователя HPOTTER и сохраняет у него привилегию SELECT:

REVOKE GRANT OPTION

FOR SELECT

ON DEPARTMENT

FROM HPOTTER;

Выполнение этого оператора приведет к каскадным отменам у всех других пользователей, которые получили право предоставлять эту привилегию от HPOTTER.

Скрипты безопасности

Если вы до сих пор задержались на этой главе, нет сомнений, что вы пришли к заключению, что реализация привилегий SQL требует набора большого объема текста. Что ж, вы правы. В действительности мы не используем интерактивные методы для выполнения этой работы. Мы пишем скрипты — или, иначе, мы пишем хранимые процедуры, которые пишут для нас скрипты.

Как правило, если мы имеем хорошо работающую схему привилегий, мы можем генерировать множество скриптов, которые формируют роли и общие полномочия. Обычно вручную написанный скрипт предназначен для полномочий EXECUTE, поскольку для этого довольно сложно создать нужную формулу.

С появлением в Firebird 1.5 оператора EXECUTE PROCEDURE, который позволяет нам обойти невозможность в Firebird выполнения операторов DDL в PSQL, мы можем выполнить групповую загрузку полномочий прямо в базу данных из хранимой процедуры. Пример подобной процедуры представлен в листинге 35.2 далее в этой главе.

Существует множество инструментов с графическим интерфейсом для тех, кто их любит. У большинства есть средства, автоматически формирующие скрипты безопасности; некоторые создают и устанавливают полномочия только для вас.

Создание скрипта

Автор предпочитает генерировать скрипт безопасности. Он может быть протестирован и аннотирован, он является документом, нужным для контроля качества, и дающим основу для распространения у пользователей. Пример подобного скрипта представлен в листинге 35.1.

Для скрипта мы можем использовать внешний файл, в который помещен скрипт — инструкции и примеры см. в главе 16, примеры также содержатся в главе 30. Однако процедура PERMSCRIPT, описанная здесь, разработана для выполнения в isql и для передачи ее выхода в текстовый файл.

Листинг 35.1. Процедура для генерации скрипта полномочий

/* (с) Helen Borrie 2004, free for use and inodxfication

under the Initial Developer’s Public License */

SET TERM ^

CREATE PROCEDURE PERMSCRIPT(

CMD VARCHAR (6) ,/* введите ‘G’ or ‘R’ */

PRIV CHAR (10) , /* привилегия или ‘ALL’ или ‘ANY’ */

USR VARCHAR(31), /* имя пользователя */

ROLENAME VARCHAR(31), /* роль, существующая или нет */

GRANTOPT SMALLINT,

/* 1 для ‘WITH GRANT[ADMIN] OPTION’ */

CREATE ROLE SMALLINT) /* 1 для создания новой роли ROLENAME */

RETURNS (PERM VARCHAR(80)) /* теоретический оператор полномочия */

DECLARE VARIABLE RELNAME VARCHAR (31); /* для имени таблицы или просмотра */

DECLARE VARIABLE STRING VARCHAR(80) = »; /* используется в процедуре */

DECLARE VARIABLE STUB VARCHAR(60) = »; /* используется в процедуре */

DECLARE VARIABLE VUSR VARCHAR(31) ; /* имя пользователя для ‘TO’ или ‘FROM’ */

DECLARE VARIABLE COMMENTS CHAR(20) = ‘/* */’;

BEGIN

/* Необходимо для некоторых редакторов пользовательского интерфейса */

IF (ROLENAME = ») THEN ROLENAME = NULL;

IF (USR = ») THEN USR = NULL;

IF (PRIV = ») THEN PRIV = NULL;

/* Недостаточно данных для выполнения работы */

IF ( (PRIV IS NULL AND ROLENAME IS NULL) OR USR IS NULL) THEN EXIT;

/* Если это имя роли, мы будем с ней работать */

IF (ROLENAME IS NOT NULL) THEN

BEGIN

/* Если задано имя роли, то создается роль, если она требуется */

IF (CREATE_ROLE = 1) THEN BEGIN

PERM = ‘CREATE ROLE ‘ || ROLENAME || ‘ ; ‘ ;

SUSPEND;

PERM = ‘COMMIT; ‘ ;

SUSPEND;

PERM = COMMENTS;

SUSPEND;

END

VUSR = ROLENAME;

END

/* Если существует имя роли, мы применим полномочия к этой роли и предоставим эту роль указанному пользователю */

ELSE

/* Нас не интересует роль: полномочия только для пользователя */

VUSR = USR;

/* Выяснение — этот скрипт GRANT или REVOKE */

IF (CMD STARTING WITH ‘G’) THEN

STUB = ‘GRANT’;

ELSE

STUB = ‘REVOKE ‘;

IF (ROLENAME IS NOT NULL) THEN

BEGIN

IF (STUB = ‘GRANT’) THEN

BEGIN

/* Предоставление роли пользователю */

STRING = STUB || ROLENAME || ‘ TO ‘ || USR;

IF (GRANTOPT = 1) THEN

STRING = STRING || ‘ WITH ADMIN OPTION ;’;

ELSE

STRING = STUB || ROLENAME || ‘ FROM ‘ || DSR || PERM = STRING;

SUSPEND;

PERM = COMMENTS;

SUSPEND;

END

/* Если передано ANY в качестве привилегии, создаем отдельно каждую привилегию */

IF (PRIV = ‘ANY’) THEN

STUB = STUB || ‘SELECT, DELETE, INSERT, UPDATE, REFERENCES ON ‘;

ELSE

STUB = STUB || PRIV || ‘ ON ‘ ;

/* Просмотр всех имен таблиц и просмотров и создание для каждого оператора */

FOR SELECT RDB$RELATION_NAME FROM RDB$RELATIONS

WHERE RDB$RELATION_NAME NOT STARTING WITH ‘RDB$’

INTO : RELNAME DO

BEGIN

STRING = STUB || :RELNAME || ‘ ‘

IF (CMD STARTING WITH ‘G’) THEN

STRING = STRING || ‘TO ‘;

ELSE

STRING = STRING || ‘FROM ‘;

STRING = STRING || VUSR;

IF (CMD STARTING WITH ‘G’

AND GRANTOPT = 1 AND ROLENAME IS NULL) THEN

STRING = STRING || ‘ WITH GRANT OPTION ;’;

ELSE

STRING = STRING || ‘ ;’;

PERM = STRING;

SUSPEND;

END

PERM = COMMENTS;

SUSPEND;

END ^

SET TERM ;^

Создание и выполнение скрипта

Перейдите в каталог Firebird /bin и запустите isql, соединитесь с базой данных как пользователь SYSDBA. Вы используете процедуру для создания скрипта, который добавит роль ‘MANDRAKE’, предоставит эту роль пользователю USER1, а потом установит полномочия для этой роли. Затем снова сделает то же самое с существующей ролью ‘PURPLE’ для пользователя USER2:

SQL> OUTPUT L:DATAEXAMPLESPERMSCRIPT.SQL;

SQL> SELECT * FROM PERMSCRIPT (‘G’, ‘ALL’, ‘USER1’, ‘MANDRAKE’, 1, 1);

SQL> COMMIT;

SQL> SELECT * FROM PERMSCRIPT (‘G’, ‘ALL’, ‘USER2’, ‘PURPLE’, 1, 0);

SQL> COMMIT; SQL> OUTPUT;

SQL> INPUT L:DATAEXAMPLESPERMSCRIPT.SQL;

SQL> COMMIT; SQL> SHOW GRANT;

Вот и все. Вы получите сообщение об ошибке, когда утилита INPUT встретит текст не SQL, напечатанный в OUTPUT, однако это не повлияет на вывод полномочий.

Инсталляция полномочий непосредственно из процедуры

Процедура GRANT_PERMS, показанная в листинге 35.2, в основном похожа на процедуру PERMSCRIPT из листинга 35.1. Вместо того чтобы создавать набор выходных строк для выполнения под isql в качестве скрипта, она непосредственно устанавливает полномочия через EXECUTE STATEMENT. Такая техника недоступна в Firebird 1,0.x.

Листинг 35.2. Процедура полномочий

/* (с) Helen Borrie 2004, free for use and modification under the Initial Developer’s Public License */

SET TERM ^;

CREATE PROCEDURE GRANT_PERMS

(CMD VARCHAR(6) ,

PRIV CHAR(10),

USR VARCHAR (31) ,

ROLENAME VARCHAR(31),

GRANTOPT SMALLINT)

DECLARE VARIABLE RELNAME VARCHAR (31);

DECLARE VARIABLE EXESTRING VARCHAR(1024) = »;

DECLARE VARIABLE EXESTUB VARCHAR (1024 ) = »;

BEGIN

IF (ROLENAME = ‘ ‘ ) THEN ROLENAME = NULL;

IF (USR = ») THEN USR = NULL;

IF (PRIV = ») THEN PRIV = NULL;

IF ((PRIV IS NULL AND ROLENAME IS NULL) OR USR IS NULL) THEN EXIT;

IF (CMD STARTING WITH ‘G’) THEN

EXESTUB = ‘GRANT ‘;

ELSE

EXESTUB = ‘REVOKE ‘;

IF (ROLENAME IS NOT NULL) THEN

BEGIN

IF (EXESTUB = ‘GRANT’) THEN

BEGIN

EXESTUB = EXESTUB || ROLENAME || ‘ TO ‘ || USR;

IF (GRANTOPT = 1) THEN

EXESTUB = EXESTUB || ‘ WITH ADMIN OPTION’;

ELSE

EXESTUB = EXESTUB || ROLENAME || ‘ FROM ‘ || USR;

EXECUTE STATEMENT EXESTUB;

END

ELSE

BEGIN

IF (PRIV = ‘ANY’) THEN

EXESTUB = EXESTUB || ‘SELECT,DELETE,INSERT,UPDATE,REFERENCES ON ‘;

ELSE

EXESTUB = EXESTUB || PRIV || ‘ ON ‘ ;

FOR SELECT RDB$RELATION_NAME FROM RDB$RELATIONS

WHERE RDB$RELATION_NAME NOT STARTING WITH ‘RDB$’

INTO : RELNAME DO

BEGIN

EXESTRING = EXESTUB || :RELNAME || ‘ ‘;

IF (CMD STARTING WITH ‘G’) THEN

EXESTRING = EXESTRING || ‘TO ‘;

ELSE

EXESTRING = EXESTRING || ‘FROM ‘;

EXESTRING = EXESTRING || USR;

IF (GRANTOPT = 1) THEN

EXESTRING = EXESTRING || ‘ WITH GRANT OPTION’;

EXECUTE STATEMENT EXESTRING;

END

END ^

SET TERM ;^

Если вы сами хотите поэкспериментировать с этими скриптами и изменить их для ваших потребностей, вы можете найти исходные тексты в разделе Download на http://www.apress.com, в файле permscripts.sql.

Пора дальше

Следующая (и последняя) глава этой части содержит множество тем, связанных с архитектурными вариантами сервера, включая раздел по инсталляции и использованию встроенного Суперсервера под Windows. Установки файла конфигурации в firebird.conf или isc config/ibconfig могут быть найдены в этой главе вместе с темой безопасности параметров конфигурации, связанных с использованием в Firebird внешних выполняемых и других файлов.

ГЛАВА 36. Конфигурация и специальные возможности.

Эта глава представляет собой попурри на темы, которые будут интересны тем разработчикам, кто хорошо знаком с практическими вопросами выполнения Firebird.

Сначала описываются архитектурные отличия между моделями Firebird Классический сервер и Суперсервер. Затем обсуждаются различные параметры конфигурации сервера и некоторые руководящие принципы разработки для встроенного сервера под Windows.

В заключение мы рассмотрим коды пользовательских внешних модулей, которые вы можете писать для использования на серверной стороне, чтобы выполнять специальные вычисления и преобразования (внешние функции), конвертирование BLOB из одного формата в другой (фильтры BLOB) и реализовывать международные наборы символов. В конце этой темы содержатся подробности по конфигурированию доступа к файловой системе сервера для этих и других внешних объектов.

Сравнение архитектуры Суперсервера и Классического сервера

Хотя Суперсервер и Классический сервер имеют много общих характеристик — действительно, они созданы из одного базового кода, — они представляют совершенно различные модели внутренних операций.

Выполняемые программы и процессы

Классический сервер выполняется как один серверный процесс на каждое соединение (рис. 36.1). Когда клиент пытается соединиться с базой данных Firebird, экземпляр исполняемого модуля fb inet_server инициализируется и продолжает оставаться предназначенным для этого клиентского соединения в течение всего времени этого соединения. Когда клиент отсоединяется от базы данных, экземпляр серверного процесса завершается.

Суперсервер выполняется как один вызов выполняемого модуля fbserver (рис. 36.2). fbserver запускается один раз системным загрузочным скриптом или системным администратором и остается запущенным, ожидая запросов на соединение. Процесс завершается явным остановом.

Рис. 36.1. Сеть Классического сервера и модель процесса

Управление блокировками

При Классическом сервере каждый клиентский процесс сервера имеет свой собственный, связанный с базой данных кэш, и множество процессов борются за доступ к базе данных. Подсистема управления блокировками, fb lockrngr, использует методы внутреннего процесса связи (Inner-Process Communication, IPC) для управления и синхронизации доступа параллельных процессов к страницам.

В Суперсервере менеджер блокировок реализован как поток процесса fbserver и использует механизмы внутрипоточной связи вместо механизма сигнализации POSIX.

Подробности внутреннего управления блокировками см. в главе 40.

Использование ресурсов

В Классическом сервере каждый экземпляр fb_inet_server выделяет в своей области памяти статический кэш для страниц базы данных. Поэтому использование ресурсов линейно возрастает с каждым дополнительным клиентским соединением. Однако, когда количество одновременных соединений относительно мало, Классический сервер использует меньше ресурсов.

Рис. 36.2. Сеть Суперсервера и модель процесса

Суперсервер использует единое пространство кэша, которое совместно используется клиентскими подключениями, что позволяет более эффективно использовать и управлять памятью кэша при большом увеличении количества одновременных соединений.

Локальный доступ

Классический сервер позволяет процессам приложений, которые выполняются на той же машине, где находятся сервер и базы данных, выполнять прямые операции ввода/вывода с базой данных.

За исключением встроенного сервера Суперсервер требует, чтобы приложения использовали сетевые методы для запросов ввода/вывода, и удовлетворяет эти запросы по сети. В Linux Суперсервер не поддерживает локальный прямой доступ.

* На платформах, отличающихся от Windows (и также рекомендовано для Windows), локальные соединения с Суперсервером через сервер localhost (с адресом IP по соглашению 127.0.0.1).

* Сервер Windows и локальный клиент могут имитировать сетевое соединение через совместно используемое пространство IPC. Этот механизм, называемый локальным доступом, не может безопасно обрабатывать множество соединений. После Firebird 1.5 он замещается локальным методом доступа с использованием подсистемы XNET.

Встроенный сервер может использовать только «локальный для Windows» метод доступа и поддерживает одно и только одно соединение с каждой локальной базой данных. Встроенный клиент может единолично соединяться с множеством локальных баз данных и получать к ним доступ через встроенный сервер. Встроенный клиент может также соединяться как обычный сетевой клиент с базами данных на других серверах.

Файл конфигурации Firebird

Firebird не требует постоянных серьезных изменений конфигурации, как это делает большинство других мощных реляционных СУБД. Однако доступен большой диапазон режимов конфигурации для настройки сервера Firebird и хост-системы, на которой он запущен.

Файл конфигурации Firebird имеет имя firebird.conf во всех версиях Firebird, начиная с 1.5. В предыдущих версиях его имя зависит от операционной системы:

* в Linux/UNIX это файл isc config;

* в Windows его имя ibconfig.

Некоторые новые параметры были добавлены в версию 1.5.

Когда при запуске процесса Firebird читается файл конфигурации, то выполняется настройка его флагов времени выполнения на значения не по умолчанию, содержащиеся в файле конфигурации. Этот файл больше не читается, пока сервер не будет заново запущен в следующий раз. Параметры конфигурации по умолчанию и их значения отображаются в файле

конфигурации, закомментированные маркерами комментариев #. Нет необходимости убирать комментарии для значений по умолчанию, чтобы сделать их видимыми процедуре запуска сервера.

Файл конфигурации может быть отредактирован любым текстовым редактором, например, vim (Linux) или Блокнот (Windows). Не копируйте этот файл с машины Windows на Linux и наоборот, поскольку две системы по-разному хранят символ перевода строки.

Параметры

Записи имеют форму.

имя-параметра = значение

имя-параметра является строкой, которая не содержит пробелов и именует конфигурируемое свойство сервера.

Значение является числом, логическим значением (1 = True, 0 = False) или строкой, что задает значение параметра.

Для установления значения любого параметра в значение не по умолчанию удалите маркер комментария (#) и отредактируйте значение.

Имена параметров Firebird 1.0.* в ibconfig/iscconfig и их синтаксис не являются равнозначными параметрам в firebird.conf. Формат, размер и количество параметров являются более ограниченными.

Формат в ibconfig/isc_config:

имя-параметра значение

Здесь пробелами между именем и его значением могут быть символы табуляции или пробелы — по желанию, что больше радует глаз. Каждая строка в файле ограничена 80 символами. Неиспользуемые параметры и значения инсталляции по умолчанию закомментированы символом #.

В Linux вы должны учитывать, что имена параметров чувствительны к регистру.

! ! !

ПРИМЕЧАНИЕ. Вы можете редактировать файл конфигурации в то время, когда сервер работает. Для активации изменений конфигурации необходимо остановить и снова запустить сервер.

. ! .

«Отсутствующие» параметры в Firebird 1.0.x

В версиях, предшествующих 1.5, некоторые необязательные параметры, которые не могли быть сконфигурированы по умолчанию, не вошли в файл конфигурации.

* Если отсутствующий параметр, принадлежащий ibconfig или isc_config, необходим для работы, он может быть добавлен.

* Если вы включите параметр, который не поддерживается в той версии, которая у вас запущена, он будет проигнорирован.

* Имена параметров и синтаксические конструкции в ibconfig/isc config не являются взаимозаменяемыми в firebird.conf.

Установки менеджера блокировок

Улучшенные установки менеджера блокировок обсуждаются позже в конце главы 40.

Параметры, связанные с файловой системой

RootDirectory

Версия 1.5 и более поздние.

Значением этого параметра является строка, задающая абсолютный путь к корневому каталогу локальной файловой системы. Этот параметр должен оставаться закомментированным, если только вы не хотите, чтобы процедура запуска заменила путь к корневому каталогу инсталляции сервера Firebird, который иначе она определяет сама. Серверы Firebird 1.5 и выше следуют заранее определенным путем для поиска корневого каталога. Логика этого пути объясняется в главе 3.

DatabaseAccess

Версия 1.5 и более поздние.

В Firebird 1.0.x сервер может соединиться с любой базой данных в его локальной файловой системе и всегда доступен приложениям, передающим абсолютный путь к файлу в файловой системе. Настоящий параметр был добавлен в версии 1.5 для более жесткого контроля безопасности при доступе к файлам базы данных и для поддержки системы алиасов базы данных. Этот параметр предоставляет возможность ограничения доступа сервера только к базам данных, имеющим алиасы, или только к базам данных, расположенным в указанных деревьях файловой системы.

DatabaseAccess может иметь Значения Full, None или Restrict.

* Full (по умолчанию) разрешает доступ к файлам базы данных в любом месте локальной файловой системы.

* None позволяет серверу соединяться только с базами данных, которые указаны в списке aliases.conf.

! ! !

ВНИМАНИЕ! Настоятельно рекомендуется установить этот режим и использовать средства алиасов баз данных. Алиасы баз данных описаны с примерами в главе 4.

. ! .

* Restrict позволяет сконфигурировать размещение доступных для подключения файлов баз данных, указывая список корневых деревьев файловой системы. Для определения разрешенных размещений задавайте список из одного или более корневых деревьев, разделяя их точкой с запятой, например:

POSIX: /db/databases;/userdir/data

Windows: D:data

Относительные пути трактуются как дополнительные к корневому каталогу установки сервера. Например, под Windows, если корневым каталогом является C:Program FilesFirebird, то следующее значение будет ограничивать доступ сервера к файлам баз данных, размещенных на CAProgram FiiesFirebirduserdata:

DatabaseAccess = Restrict userdata

Параметры для конфигурирования временного пространства для сортировки

Когда размер внутреннего буфера сортировки слишком мал для размещения строк, включенных в операцию сортировки, для Firebird требуется создание временных файлов для сортировки в файловой системе сервера. По умолчанию он будет отыскивать путь, заданный в переменной окружения INTERBASE_TMP. Если эта переменная не указана, он постарается использовать путь /tmp в файловой системе Linux/UNIX или C:Temp в Windows NT/2000/XP. Ни одно из этих размещений не может конфигурироваться для задания размера.

В Firebird существует параметр для определения дискового пространства, которое будет использовано для хранения таких временных файлов. Будет разумным его применять, чтобы гарантировать, что достаточное пространство для сортировки будет доступным при любых условиях.

Все запросы CONNECT или CREATE DATABASE совместно используют один и тот же список каталогов для временных файлов, и каждый запрос создает свои собственные временные файлы. Файлы сортировки освобождаются при завершении сортировки или при отмене запроса.

В версии 1.5 имя этого параметра изменилось с tmp_directory на TempDirectories. Также поменялся и синтаксис значения параметра.

TempDirectories

Версия 1.5 и более поздние.

Предоставляет список из одного или более каталогов, разделенных точкой с запятой (;), где могут сохраняться файлы сортировки. Каждый элемент может включать необязательный аргумент размера в байтах для ограничения хранения. Если этот аргумент опущен или задан неверно, Firebird будет использовать пространство в этом каталоге, пока не исчерпает его объем, а после чего перейдет к следующему каталогу в списке, например:

POSIX: /db/sortfilesl 100000000;/firebird/sortfiles2

Windows: E:sortfiles 500000000

Относительные пути трактуются относительно пути, который запущенный сервер распознает как корневой каталог инсталляции Firebird. Например, в Windows, если корневым каталогом является C:Program FilesFirebird, то следующее значение сообщит серверу, что он должен сохранять временные файлы в C:Program FilesFirebirduserdatasortfiles с ограничением размера примерно в 477 Мбайт:

TempDirectories = userdatasortfiles 500000000

tmp_directory

Версии до Firebird 1.5.

Синтаксис старого значения для tmp directory требует включения одной строки tmp_directory для каждого каталога, в котором вы хотите сохранять временные файлы сортировки. Задавайте количество байтов, доступных в каждом каталоге, и в кавычках путь к каталогу, который существует на физическом накопителе с достаточным объемом свободной памяти. Вы можете перечислить множество записей, по одной на строке; пространства не обязательно должны быть смежными или размещаться на одном устройстве хранения данных.

Пример. Следующие записи задают список в одном файле конфигурации:

tmp_directory 6000000 «d:fbtemp»

tmp_directory 12000000 «f:fbtemp»

tmp_directory 4000000 «w:backwash»

Путь должен быть заключен в двойные кавычки, иначе сервер проигнорирует эту запись. Пространство будет использовано в соответствии с порядком задания. Если будет выбрано пространство в одном конкретном каталоге, Firebird создаст новый временный файл в следующем каталоге из списка каталогов. Если же больше нет записей в списке каталогов, Firebird выдаст сообщение об ошибке и остановит обработку текущего запроса.

Параметры, связанные с ресурсами

CpuAffinityMask

Версии 1.5 и выше под Windows.

cpu_affinity

Версии до Firebird 1.5 под Windows.

В Суперсервере Firebird под Windows могут быть проблемы с операционной системой, постоянно переключающей процесс Суперсервера туда и сюда между процессорами на машинах SMP. В списках поддержки это называется «эффектом качелей» и на таких системах он может оказывать сильное воздействие на производительность. Данный параметр должен быть использован для установки одного или более конкретных процессоров для Суперсервера Firebird.

Параметры CpuAffinityMask и cpu?affinity получают значение целого числа: маску CPU. Например:

CpuAffinityMask = 1

cpu_affinity = 1

Суперсервер запускается только на первом процессоре (CPU 0).

CpuAffinityMask = 2

cpu_affinity = 2

Запускается только на втором процессоре (CPU 1).

CpuAffinityMask = 3

cpu_af finity = 3

Запускается на первом и на втором процессорах.

! ! !

ВНИМАНИЕ! Этот параметр не работает в Windows 9х или ME, поскольку он использует вызов NT API. Версии Windows 9х не могут использовать более одного процессора.

. ! .

Вычисление значения CpuAffinityMask

Вы можете использовать этот параметр для установления свойства Firebird для любого одного процессора или (для Классического сервера) любой комбинации процессоров, установленных в системе.

Рассматривайте центральные процессоры как массив, пронумерованный от 0 до n-1, где n- количество установленных процессоров, i — номер в массиве конкретного процессора. M- другой массив, содержащий значение маски (Maskvaiue) для каждого выбранного CPU. Значение А является суммой значений в массиве M.

Используйте следующие формулы для получения Ми вычисления Maskvaiue А:

Mi = 2l

А = М1+М2 + M3 …

Например, для выбора первого и четвертого процессоров (процессор 0 и процессор 3) вычислите:

А = 20 + 23 = 1 + 8 = 9

! ! !

ВНИМАНИЕ! Серверы Firebird версии 1.5 и ниже могут не поддерживать Нурег-Threading на некоторых ранних моделях материнских плат. Для устранения проблем балансировки нагрузки может оказаться необходимым отменить Hyper-Threading на уровне BIOS системы.

. ! .

Маска процессоров по умолчанию 1 (процессор 0).

DefaultDbCachePages

Версия 1.5 и более поздние.

database_cache_pages

Версии, предшествующие Firebird 1.5.

Устанавливает глобальное для сервера значение по умолчанию (целое число) количество страниц базы данных, выделяемых в памяти для каждой базы данных. Сконфигурированное значение может быть перекрыто на уровне базы данных.

Значение по умолчанию для Суперсервера 2048 страниц. Для Классического сервера — 75.

Суперсервер и Классический сервер выделяют и используют кэш-память по-разному. Не существует «формулы», которую можно было бы применить для установки оптимального значения по умолчанию размера кэша, который подошел бы для всех случаев. Тем не менее факторы, влияющие на производительность, подробно обсуждаются в разд. «Кэш базы данных» главы 15.

EventMemSize

Версия 1.5 и более поздние.

Это целое число, задающее количество байтов памяти, выделяемой для менеджера событий. Значение по умолчанию 65 536 (64 Кбайт).

SortMemBlockSize

Версия 1.5 и более поздние.

Этот параметр позволяет сконфигурировать размер в байтах каждого блока памяти, используемого для модуля внутренней сортировки. Значение по умолчанию при инсталляции 1 Мбайт, который вы можете заменить любым значением, не превышающим текущее значение максимума, установленного в параметре sortMemupperLimit.

SortMem UpperLimit

Версия 1.5 и более поздние.

Максимальный размер памяти в байтах, выделяемой для модуля внутренней сортировки. Значение по умолчанию при инсталляции 67 108 864 байт (64 Кбайт) для Суперсервера и 8 388 608 байт (8 Кбайт) для Классического сервера.

! ! !

ВНИМАНИЕ! Для Классического сервера значение по умолчанию слишком велико, если только не подключено большое количество клиентов. Помните, что увеличение размера любого блока или максимального ограничения в Классическом сервере влияет на каждое клиентское соединение (экземпляр сервера) и увеличивает потребление сервером памяти в линейной пропорции.

. ! .

Параметры, связанные с коммуникацией

ConnectionTimeout

Версия 1.5 и более поздние.

connection_timeout

Версии, предшествующие Firebird 1.5.

Задает количество секунд ожидания до прекращения попытки соединения. Значение по умолчанию 180.

DummyPacketlnterval

Версия 1.5 и более поздние.

dummy_packet_interval

Версии, предшествующие Firebird 1.5.

Это старый параметр InterBase, устанавливающий количество секунд (целое число), в течение которых сервер должен ждать молчания клиентского соединения, прежде чем отправить пустой пакет для подтверждения запроса. По умолчанию устанавливается в 0 (отключено) для Firebird 1.5 и в 60 для Firebird 1.0.x.

! ! !

ВНИМАНИЕ! Этот параметр не должен использоваться в Windows совсем, и он не рекомендуется для других операционных систем^[139].

. ! .

В Firebird 1.0.x откройте iboonfig (Windows) или iso config (другие системы) и добавьте строку:

dummy_packet_interval=0

Обычно Firebird отслеживает активные соединения с использованием режима разъема SO_KEEPALIVE с периодом по умолчанию 2 часа. Если вам нужно изменить период ожидания, подрегулируйте установки сервера^[140]:

* для сервера POSIX измените содержание proc/sys/net/ipv4/tcp_keepalive_*;

* для Windows просмотрите инструкции в статье на http://support.microsoft.com /default.aspx?kbid=140325.

RemoteServiceName

Версия 1.5 и более поздние.

Это имя сервиса на сервере. Если файл firebird.conf включен только в клиентскую инсталляцию (см. главу 7), то клиент при необходимости будет отыскивать в нем имя сервиса. См. также RemoteServicePort (описан в следующем разделе). Более подробную информацию см. в разд. «Конфигурирования порта сервиса» главы 2.

Default = gds_db

RemoteServicePort

Версия 1.5 и более поздние.

Этот параметр и RemoteServiceName обеспечивают возможность перекрытия либо имени сервиса TCP/IP, либо номера порта TCP/IP, используемых для прослушивания запросов клиентов к соединению с базой данных, если один из них отличается от значения по умолчанию при инсталляции (gds_db и порт 3050).

Изменяйте одну запись, но не обе. RemoteServiceName проверяется первым на соответствие записи в файле services. Если есть соответствие, то конфигурируется номер порта для RemoteServicePort. Если нет соответствия, то используется номер порта по умолчанию при инсталляции — 3050.

! ! !

ПРИМЕЧАНИЕ. Если номер порта указывается в строке соединения TCP/IP, то он всегда имеет приоритет перед RemoteServicePort.

. ! .

RemoteAuxPort

Версия 1.5 и более поздние.

Унаследованное от InterBase поведение, связанное с передачей сообщений о событиях по сети через случайно выбранные порты TCP/IP, показывает, что в некоторых

типах инсталляций это является источником постоянных ошибок сети и конфликтов средств межсетевой защиты (firewall), иногда приводит к краху сервера. Этот параметр позволяет сконфигурировать один порт TCP для всего трафика сообщения о событиях.

Значение инсталляции по умолчанию (0) сохраняет традиционный случайный выбор порта. Для назначения одного порта для сообщений о событиях используйте целое число, которое задает номер доступного порта.

RemoteBindAddress

Версия 1.5 и более поздние.

По умолчанию клиенты могут соединяться из любого сетевого интерфейса, для которого сервер поддерживает трафик. Этот параметр позволяет вам связывать сервис Firebird с приходящими запросами через один IP-адрес (т. е. сетевую карту) и отклонять запросы на соединение от любых других сетевых интерфейсов. Это позволяет разрешать проблемы в некоторых сетях, где сервер используется в нескольких подсетях.

Это строка в допустимом формате IP с использованием разделительных точек. Значением по умолчанию является пустая строка.

TcpRemoteBufferSize

Версия 1.5 и более поздние.

Ядро сервера вначале считывает клиента и может отправить некоторые строки данных в одном пакете. Чем больше размер пакета, тем большая строка отправляется за одну пересылку. Используйте этот параметр (с осторожностью и полным пониманием его воздействия на производительность сети), если вам нужно увеличить или уменьшить размер пакета TCP/IP. Параметр воздействует и на сервер, и на клиента.

Значением является целое число (размер пакета в байтах) в диапазоне от 1448 до 32 767. Значением по умолчанию при инсталляции является 8192.

Параметры, специфичные для POSIX

RemoteFileOpenAbility

Версия 1.5 и выше, только для POSIX.

! ! !

ВНИМАНИЕ! Используйте RemoteFileOpenAbility только с особой осторожностью.

. ! .

Это логический параметр, который, будучи установленным в True, позволяет серверу открывать файлы, которые расположены в монтированных разделах сетевой файловой системы (Networked FileSystem, NFS). Он предназначен для создания оперативных копий на накопителях в NFS, которые имеют высокую доступность. Он не является безопасным для файлов базы данных — возможно, за исключением баз данных только для чтения — потому что эта файловая система находится вне контроля локальной файловой системы. Он не должен использоваться для целей открытия любых баз данных для чтения/записи, чья выживаемость имеет для вас значение.

TcpNoNagle

Версия 1.5 и выше, только для Linux.

tcp_no_nagle

Версии до Firebird 1.5, только для Linux.

По умолчанию в Linux библиотека sockets будет минимизировать отправку данных путем буферизации перед фактической пересылкой данных, используя при этом внутренний алгоритм (реализованный как режим TCP_NODELAY при канальном соединении), называемый алгоритмом Nagle. Он был разработан для исключения проблем с пересылкой большого числа малых пакетов в медленных сетях.

По умолчанию параметр TCP NODELAY включен (значение 0) при инсталляции в Linux Суперсервера Firebird. В медленных сетях его отключение может увеличить скорость. Остерегайтесь двойного отрицания — устанавливайте значение параметра в True для отключения TCP_NODELAY и В False для его включения^[141].

В версиях 1.5 и выше эта возможность активна только для Суперсервера.

Параметры, специфичные для Windows

CreatelnternalWindow

Версия 1.5 и выше, только для Windows.

Протокол «локального Windows» использует скрытое окно для IPC (InterProcessor Communication, межпроцессорная связь) между локальным клиентом и сервером. Это окно IPC создается при запуске сервера, когда CreatelnternalWindow имеет значение True (1, по умолчанию). Установите его в 0 (отключен) для запуска сервера без этого окна и, следовательно, без локального протокола. При отключенном локальном протоколе возможен одновременный запуск множества серверов.

DeadThreadsCollection

Версия 1.5 и выше, только для Windows.

Задается для планировщика потоков в Windows. Этот целочисленный параметр устанавливает величину приоритета переключения циклов (см. разд. «PrioritySwitchDeloy»), которое выполняется планировщиком перед разрушением (или закрытием) потока.

Немедленное разрушение (или закрытие) рабочих потоков может потребовать семафоров и блокирующих вызовов, создающих значительные непроизводительные издержки. Вместо этого планировщик потоков поддерживает потоки в пуле. Когда поток завершит свою задачу, он отмечается как свободный. Незанятый поток разрушается (или закрывается) после n итераций цикла планировщика, где n — значение параметра DeadThreadsCoilection.

Для сервера, обрабатывающего очень большое количество соединений, — сотни и более — значение этого параметра должно быть больше его значения по умолчанию 50.

GuardianOption

Версия 1.5 и выше, только для Windows.

Этот логический параметр используется на серверах Windows для задания, будет ли Guardian перезапускать сервер каждый раз, когда он завершится аварийно. Значение по умолчанию при инсталляции требует этого (1 = True). Для отмены рестарта отключите этот параметр (0 = False).

IpcMapSize

Версия 1.5 и выше.

server_client_mapping

Версии, предшествующие Firebird 1.5.

Это размер в байтах клиентской порции отображаемого в памяти файла, используемого для IPC в модели соединения, применяемой для «локального соединения Windows». Параметр не имеет эквивалента для других платформ и не оказывает никакого влияния на сетевые соединения. Значением является целое число от 1024 до 8192. Значение по умолчанию 4096.

Увеличение значения может улучшить производительность при поиске очень большого набора строк данных, такого как графические BLOB.

! ! !

ПРИМЕЧАНИЕ. Если Firebird выполняется как приложение, эта установка также может быть изменена в диалоге системной панели Guardian. Остановите и запустите сервер, чтобы новые установки начали действовать.

. ! .

IpcName

Версия 1.5 и выше, только для платформ Windows.

Значение по умолчанию FirebirdlPI.

Это имя разделяемой области памяти, используемой как транспортный канал в локальном протоколе.

Значение по умолчанию в версии 1.5 FirebirdiPi не совместимо ни со старыми версиями Firebird, ни с InterBase. При необходимости используйте значение interBaseiPi для сохранения совместимости с существующим приложением, которое ссылается на разделяемую память (пространство IPC) по имени.

MaxUnflushed Writes

Версия 1.5 и выше.

Применимо только для серверов Windows.

Этот параметр был введен в версии 1.5 для обработки ошибок в операционных системах сервера Windows, из-за которых асинхронный вывод никогда не записывался на диск, за исключением случая, когда сервер Firebird закрывался. (Асинхронный вывод не поддерживается в Windows 9х и ME.) Поэтому в системах 24/7 (работающих 24 часа в сутки, 7 дней в неделю) асинхронный вывод вообще никогда не выполнялся.

Этот параметр определяет, как часто требующие вывода страницы будут записываться на диск при отключенном режиме Forced Writes (включен асинхронный вывод). Его значением является целое число, которое определяет максимальное количество требующих вывода страниц, при достижении которого отмечается необходимость вывода после того, как в следующий раз будет подтверждена транзакция. Значение по умолчанию 100 для инсталляций Windows и -1 (отключено) для всех других платформ.

Если конец цикла MaxunfiushedwriteTime (см. следующий раздел) будет достигнут до того, как счетчик ожидающих вывода страниц достигнет значения Maxunfiushedwrites, флаг вывода будет отмечен немедленно, а счетчик количества ожидающих вывода страниц будет установлен в ноль.

MaxUnflushed Write Time

Версия 1.5 и выше.

Применимо только для серверов Windows.

Этот параметр определяет максимальное значение промежутка времени, через который ожидающие вывода страницы при асинхронном выводе будут записываться на диск при отключенном режиме Forced Writes (включен асинхронный вывод). Его значением является целое число, которое задает интервал в секундах между последним выводом на диск и установкой флага для выполнения вывода после того, как в следующий раз будет подтверждена транзакция. Значение по умолчанию 5 секунд для инсталляций Windows и — 1 (отключено) для всех других платформ.

PrioritySwitchDelay

Версия 1.5 и выше, только для Windows.

Устанавливается для планировщика потоков в Windows. Целое число задает время в миллисекундах, которое должно пройти, прежде чем приоритет неактивного потока будет уменьшен до LOW (низкий) или приоритет активного потока будет увеличен до HIGH (высокий). Одна итерация по этой последовательности переключений представляет один цикл планировщика потоков.

Значением по умолчанию является 100 миллисекунд; это время выбрано на основании экспериментов с процессорами Intel PIII/P4. Для процессоров с меньшим быстродействием потребуется большее время задержки.

PriorityBoost

Версия 1.5 и выше, только для Windows.

Это целое число задает количество дополнительных циклов, предоставляемых потоку, когда его приоритет переключается на HIGH. Значение по умолчанию при инсталляции 5.

ProcessPriorityLevel

Версия 1.5 и выше, только для платформ Windows.

Это параметр для установки приоритета уровень/класс для серверного процесса; он заменяет параметр server_priority_ciass в версиях, предшествующих 1.5, новой реализацией.

Значением параметра является целое число:

* 0: обычный приоритет;

* положительное значение: высокий приоритет (то же самое, что и переключатель -B[oostPriority] в режимах configure и start у instsvc.exe);

* отрицательное значение: низкий приоритет.

! ! !

ПРИМЕЧАНИЕ. Все изменения этого значения должны быть тщательно протестированы, чтобы убедиться, что они действительно приводят к соответствующей реакции сервера на запросы.

. ! .

server_priority_ class

Версии, предшествующие Firebird 1.5.

Этот параметр назначает класс приоритета для сервиса Firebird только в Windows NT или Windows 2000. Возможными значениями являются: 1 = низкий приоритет, 2 = высокий приоритет. Значение по умолчанию 1.

RemotePipeName

Версия 1.5 и выше, применим только на платформах Windows для соединений именованных каналов (named pipes).

Этот строковый параметр является именем канала, используемого в качестве транспортного канала для сетей Windows именованных каналов. Именованный канал является эквивалентом номера порта в TCP/IP. Значение по умолчанию, interbas, совместимо с предыдущими реализациями Firebird и с InterBase.

server_working_size_max и server_working_size_min

Версии, предшествующие Firebird 1.5.

Это два устаревших параметра, унаследованные от предыдущих версий Firebird. Сейчас они не поддерживаются и исключены из firebird.conf.

Параметры совместимости

CompleteBooleanEvaluation

Версия 1.5 и выше.

Устанавливает метод вычисления логических значений (полный или сокращенный). Значение по умолчанию (0 = False) задает сокращенное вычисление выражений, содержащих предикаты AND или OR, при котором возвращается результат «истина» или «ложь», когда дальнейшее вычисление оставшейся части выражения уже не повлияет на результат.

При весьма редких (обычно исключаемых) условиях может произойти такое, что операция внутри условий AND или OR, которая не будет вычисляться при сокращенном поведении, может потенциально повлиять на окончательный результат. Если у вас такая беда, и вы получили приложение, которое использует такие характеристики в логике SQL, вам понадобится использование этого параметра для обеспечения полного вычисления, пока у вас не появится удобный случай хирургического вмешательства в эту ситуацию. Это параметр логического типа.

! ! !

ВНИМАНИЕ! Не рассматривайте этот факт как флаг, который влияет на все логические вычисления, выполняемые в любых базах данных на сервере.

. ! .

OldParameterOrdering

Версия 1.5 и выше.

Версия 1.5 учитывает старую ошибку InterBase, которая приводит к тому, что выходные параметры возвращаются клиенту в структуре XSQLDA в порядке, вызывающем у пользователя аллергию. Эта ошибка сохранялась столь долго, что многие существующие приложения, драйверы и интерфейсные компоненты имели встроенные средства для корректировки данной проблемы на клиентской стороне^[142].

Версия 1.5 и более поздние учитывают наличие корректировок в API и инсталлируются С OldParameterOrdering = 0 (False). Установите этот логический параметр В True (1), если вам нужно вернуться к старым условиям для совместимости с существующим кодом.

Параметры, связанные с внешними объектами

Выбор и установки значений параметров для модулей внешних кодов и файлов данных обсуждаются в конце разд. «Конфигурирование внешних размещений».

Работа со встроенным сервером

Встроенный сервер для Windows имеет те же возможности, что и Суперсервер, за исключением поддержки множества пользователей и защиты по паролю. Клиентская библиотека включена в сервер, и эта объединенная пара выполняет работу как клиента, так и сервера для одного и только одного подключенного приложения.

! ! !

ПРИМЕЧАНИЕ. Встроенный сервер для Windows не поддерживается в версиях, предшествующих версии 1.5.

. ! .

Когда встроенный сервер отыскивает корневой каталог его инсталляции, он игнорирует любые записи в реестре и переменную окружения FIREBIRD. Он трактует как корневой тот каталог, в котором размещается его двоичный файл (fbembed.dll, переименованный в fbclient.dll или gds32.dll).

Вы должны иметь полный набор файлов, требуемых для встроенного сервера, в корневом каталоге каждого встроенного приложения. Если используются внешние файлы (поддержка международных языков, библиотеки UDF, библиотеки фильтров BLOB), встроенному серверу нужно найти в этом корневом каталоге или ниже firebird.conf, а в firebird.conf параметр RootDirectory должен указывать на каталог, в котором располагается файл библиотеки встроенного сервера. См. пример в разд. «Встроенный сервер» главы 1.

Запуск встроенного сервера

Единственным допустимым протоколом соединения является «локальный Windows». Встроенный сервер не поддерживает локальный loopback-протокол или любой из сетевых протоколов.

Поставляемое приложение хорошо сконфигурировано, и у сервера не будет конфликтов с другими запущенными серверами Firebird или клиентами. Серверный процесс будет запущен, как только приложение успешно соединится с локальной базой данных.

Приложения

Любое приложение, которое уже работает с полным сервером и локальным или удаленным клиентом, будет нормально работать и со встроенным сервером. Четыре детали вы должны учесть в ваших существующих приложениях:

* размещение и именование библиотеки встроенного сервера;

* жестко закодированный путь к базе данных;

* написанные вами утилиты, которые используют удаленный менеджер сервисов;

* безопасность и целостность как следствие того, что интерфейс приложения не проверяет полномочия пользователя по доступу к серверу.

Размещение и переименование библиотеки

Для встроенного сервера- распространяемого как fbembed.dll- нет проблем с переименованием этой библиотеки в имя gds32.dll или fbclient.dll, или любое другое нужное имя. Для того чтобы пакет встроенного сервера был самодостаточным, эта библиотека должна находиться в том же каталоге, что и выполняемый модуль приложения, а дополнительные файлы и каталоги для функций сервера размещались так, как рекомендовано в главе 1.

Если у вас на одной и той же машине много приложений встроенного сервера, которым нужна для использования эта библиотека, то существует несколько вариантов.

* Поместите копию библиотеки в корневой каталог каждого приложения и разместите дополнительные файлы и каталоги так, как рекомендовано в главе 1. Это наиболее предпочитаемый вариант, т. к. он делает «пакет» простым для поставок при инсталляции и независимым от структуры существующей файловой системы. При этом если вы хотите устанавливать множество пакетов встроенного сервера на одной и той же рабочей станции, то появится проблема избыточности.

* Поместите единственную копию библиотеки в некоторый специальный каталог- с дополнительными файлами и каталогами, корректно поименованными и размещенными относительно этой библиотеки — и создайте в реестре ключ, который будет читать каждое приложение в его аргументы загрузки библиотеки. Возможно, это менее привлекательно с точки зрения перспектив переносимости, но это упростит проблемы конфликтов и обновления.

* Поместите библиотеку- подходящим образом именованную- в системный каталог и используйте переменную пути FIREBIRD для указания корня древовидной структуры, где расположены дополнительные файлы и каталоги. Этот вариант будет работать только в системе, где не выполняется полный сервер Firebird версии 1.5 или выше. К тому же он повышает вероятность перезаписи этой библиотеки другими инсталляторами.

! ! !

ПРИМЕЧАНИЕ. Помните, что некоторые продукты Borland жестко запрограммированы на распознавание внутренних версий строк только для Borland. Даже если имя и размещение в файловой системе являются «корректными» для элементов Borland, ограничение строки версии может сделать ваше приложение несовместимым со встроенным сервером. Например, приложения, скомпилированные с использованием оригинальных компонентов InterBaseXpress (IBX), не будут соединяться cfbembed.dll без внесения изменений.

. ! .

Жестко закодированные пути к базе данных

Строка соединения, например, WlNSERVER:C:Program FilesFirebirdFirebird 1 5 employee.fdb, жестко закодированная в вашем приложении, явно вызовет проблемы при установке вашего программного обеспечения на другой машине. Ваш код должен адаптироваться к размещению базы данных, что неизвестно во время проектирования и часто ограничено локальным (не localhost) соединением. Это не является проблемой, появившейся в случае со встроенным сервером. Нам часто нужно поставлять наше программное обеспечение приложений клиент/сервер с предоставлением пользователям или системным администраторам возможности конфигурирования размещения баз данных в сети и в файловой системе.

Система алиасов баз данных позволяет вам компилировать приложения с «мягкими» путями файловой системы к базе данных. Каждый раз, когда код приложения ссылается на сегмент пути в строке соединения, то используется алиас, и определение размещения в файловой системе становится задачей поиска установок в aliases.conf.

Предположим, например, что вы решили использовать EMPDATA В качестве алиаса. В файле aliases.conf на вашей машине разработки вы указали для алиаса ваш путь:

EMPDATA = C:Program FilesFirebirdFirebird_1_5employee.fdb На другой машине это может быть:

EMPDATA = D:databasesemployee.fdb

Это решает вопрос с сегментом пути и исключает один уровень сложности. Причем у вас еще может остаться проблема с протоколом соединения. Могут потребоваться некоторые изменения, если приложение жестко закодировано на имя хоста и формат строки для соединения TCP/IP или именованных каналов.

Утилиты удаленных сервисов

Утилиты, использующие Services API или старые переключатели менеджера сервисов для удаленного администрирования, должны быть отключены или адаптированы к работе с локальным протоколом. Конкретные меры будут зависеть от того, как реализована ваша архитектура клиент/сервер. Если ваше существующее приложение предоставляет возможности, которые обеспечивают безопасность и стабильность сервера, вам также нужно рассмотреть реализацию обращения приложения к серверу, где по существу обходится идентификация пользователя.

Вопросы безопасности сервера

Любая библиотека встроенного сервера, размещенная на машине, где находится и база данных, потенциально является Троянским конем. На уровне сервера средства безопасности оперируют в предположении, что любой пользователь, соединяющийся с базой данных, будет идентифицироваться через базу данных безопасности security.fdb. Однако, когда встроенный сервер подключает клиента, идентификация пользователя с его паролем пропускается. Поскольку любой пользователь способен соединиться с любой базой данных, безопасность сервера будет легко отменена, если только серверная машина не будет защищена физически.

Можно написать приложение встроенного сервера, которое «соединится как пользователь SYSDBA», используя вообще что угодно в качестве пароля SYSDBA. Не существует никакого способа, чтобы сервер сообщил, что пользователь SYSDBA «прошел через стеклянный потолок» без допустимого пароля. Если SYSDBA активен в любой базе данных, то этот пользователь сможет соединяться и вытворять все, что ему захочется без каких-либо ограничений. Любой, кто имеет доступ к вашей сети и имеет привилегии к файловой системе на сервере, может установить злонамеренное приложение встроенного сервера, которое сможет читать и писать любые данные в ваши базы данных или вовсе их удалить.

Помните, что база данных безопасности (security.fdb) является такой же базой данных, как и другие. Пользователь SYSDBA имеет к ней специальные привилегии SQL — как и ко всем базам данных — для создания, модификации и удаления чего угодно.

Подготовленная машина для баз данных защищена от физических вторжений и неавторизованного доступа к файловой системе, «вошедший» в базу данных пользователь, не являющийся SYSDBA, будет субъектом обычных ограничений привилегий SQL. Привилегии SQL к объектам данных в базах данных Firebird применяются на основе «участия» — никакой пользователь, за исключением SYSDBA и владельца базы данных, не имеет автоматических прав к любым объектам любых баз данных.

Поэтому все еще необходимо предоставить способ для пользователя (или приложения) передавать имя пользователя и, желательно, роль обычной процедуре подключения. Разработчики должны предоставлять и привилегии защиты, и охранную процедуру.

См. главы 34 и 35 по вопросам безопасности доступа к серверу и привилегиям SQL к объектам базы данных.

Совместимость нескольких серверов

Любое количество приложений встроенного сервера может выполняться одновременно без каких бы то ни было конфликтов. Однако невозможно нескольким встроенным серверам иметь одновременный доступ к одной базе данных по причине блокировки, применяемой в архитектуре Суперсервера при первом успешном подключении.

Обычные серверы Firebird и InterBase могут без конфликтов одновременно выполняться на машине, на которой запущены встроенные серверы. Для доступа локального клиента следует обратить внимание на исключение конфликта пространства имен между обычными клиентскими библиотеками (gds32.dll и fbclient.dll) и именем, выбранным для библиотеки встроенного сервера.

«Клиентская» часть fbembed.dll может быть обычным, удаленным клиентом других серверов; в то же самое время она внутренне связывается со своим встроенным сервером.

Останов встроенного сервера

Выполнение встроенного сервера не может быть остановлено кроме как при завершении клиентского приложения. Ваше приложение должно завершаться с обычным завершением транзакций и отключением от всех баз данных.

Модули внешних кодов

Firebird может расширить свои возможности путем доступа к определенным пользователям подпрограммам, написанным на включающем языке программирования и скомпилированным во внешние библиотеки общего доступа. Этот раздел содержит рассмотрение некоторых вопросов и техник, относящихся к написанию внешних функций (UDF) и фильтров BLOB.

* Внешние функции: Firebird «путешествует налегке» в отношении встроенных функций. Вместо того чтобы навешивать на сервер огромную библиотеку скрытых функций, Firebird позволяет разработчикам выбрать — и, при необходимости, определить- их собственные библиотеки внешних функций, которые соответствуют потребностям вычислений и выражений в их базах данных. Функции, определенные пользователем (User-Defined Function, UDF), добавляют высокую гибкость в среду вашей базы данных. UDF являются расширением функций сервера Firebird на серверной стороне; они объявляются для баз данных и выполняются в контексте серверного процесса.

Как и стандартные встроенные функции SQL, UDF могут быть разработаны для выполнения конвертирования данных или для вычислений, которые сложно или вообще невозможно выполнить в языке SQL. UDF включают функции для статистики, строк, дат и математических вычислений.

В разд. «Внешние функции» главы 21 подробно объясняется, как размешать, объявлять и использовать внешние функции, а также как сконфигурировать их размещение в файловой системе, чтобы исключить некоторые риски безопасности и целостности, существующие при выполнении внешнего кода вместе с ядром сервера. Конфигурация по умолчанию и режимы файловой системы также обсуждались ранее в этой главе при рассмотрении параметров udfAccess (версия 1.5) и externaI_fiIe_directory (версия 1,0.x).

* Фильтры BLOB: сервер Firebird использует несколько внутренне определенных подпрограмм для преобразования байтовых потоков из одного формата в другой. Эти подпрограммы называются фильтрами BLOB. Обработчик SQL представляет их в DDL и в метаданных в виде подтипов BLOB. Существует также возможность писать свои собственные фильтры BLOB для преобразования данных BLOB из одного формата в другой совместимый формат. Например, фильтр BLOB может конвертировать формат XML в формат RTF или изображение BMP в JPEG.

Разработка ваших собственных UDF

Библиотеки UDF компилируются как стандартные библиотеки совместного использования и выполняются на сервере, где размещена база данных. Библиотеки динамически загружаются базой данных во время выполнения, когда на библиотеку ссылается выражение SQL. Вы можете создавать библиотеки UDF на любой платформе, которая поддерживается в Firebird. Для использования одного и того же набора библиотек UDF в базах данных, выполняющихся на различных платформах, создайте и скомпилируйте отдельные библиотеки для каждой платформы, где располагается база данных.

Библиотека в этом контексте является совместно используемым объектом, который обычно имеет расширение dll на платформе Windows, расширение so для UNIX и Solaris и расширение si на HP-UX. Она может содержать одну или более точек входа для функций, определенных пользователем.

! ! !

СОВЕТ. Каталог Firebird /examples содержит некоторые старые примеры make- файлов (makefile.be и makefile.msc для систем Windows, makefile для UNIX), которые создают библиотеку ib_udf function из ib_udf.c.

. ! .

Процесс создания UDF состоит из четырех шагов:

1. Напишите функцию на любом языке программирования, который может создавать библиотеки совместного использования. Функция может принимать ограниченное количество входных параметров, но она должна возвращать один и только один результат. Функции, написанные на Java, не поддерживаются.

2. Скомпилируйте функцию и свяжите с динамически связываемой библиотекой (DLL) или с библиотекой совместно используемых объектов (SO) в соответствии с платформой.

3. Поместите библиотеку и любые требуемые символические ссылки в подходящее место на диске на серверной машине так, чтобы сервер мог получить к ней доступ в каталог по умолчанию /UDF или в альтернативный каталог, который вы сконфигурировали для библиотек внешних функций.

4. Используйте DECLARE EXTERNAL FUNCTION для объявления каждой индивидуальной UDF для каждой базы данных, в которой вам нужно ее использовать.

! ! !

ПРИМЕЧАНИЕ. Очень хорошей практикой является создание скрипта, содержащего объявления ваших UDF и некоторых комментариев, объясняющих использование.

. ! .

Написание модуля функции

На языке С UDF пишутся как любые стандартные функции. UDF может получать до десяти входных параметров и должна возвращать одно и только одно значение данных в качестве результата.

Исходный код модуля может определять одну или более функций. Если вы включите заголовочный файл Firebird ibase.h в ваш каталог Firebird /include при компиляции, ваш модуль С или C++ сможет использовать имеющиеся в нем определения типов (typedef). Возможности трансляции существуют и для других языков, включая Delphi. Например, исходный пакет для FreeUDFLib^[143] от Gregory Deatz включает ibase.pas.

Задание параметров

Параметры, не являющиеся BLOB или массивами, передаются функциям UDF либо по ссылке^[144] с использованием типов данных включающего языка, допускающих преобразование в соответствующие типы данных Firebird, либо через дескриптор, используя предварительно определенную структуру, которая описывает тип данных Firebird во включающем языке. Может быть принято до десяти параметров, соответствующих любому типу данных Firebird за исключением

массива или элемента массива. Если UDF возвращает BLOB, то количество входных параметров ограничивается девятью.

В качестве примера передачи параметров по ссылке можно рассмотреть объявление функции в языке С FN_ABSO, которая принимает один параметр, имеющий в С тип double. Когда вызывается FN_ABS(), ей должен передаваться параметр, имеющий в SQL тип данных DOUBLE PRECISION.

Передача параметров через дескриптор появилась в Firebird 1.0, что позволяет передавать родные типы данных Firebird. Для некоторых внешних функций это упрощает обработку параметров NOLL и дает возможность перекрывать объявления. Структуру дескриптора параметра можно найти в ibase.h:

typedef struct paramdsc {

unsigned char dsc_dtype;

signed char dsc_scale;

ISC_OSHORT dsc_length;

short dsc_sub_type;

ISC_USHORT dsc_flags;

unsigned char *dsc_address;

} PARAMDSC;

Самое важное поле в структуре, конечно, dsc_dtype, потому что оно ответственно за трансляцию родных типов данных Firebird в типы данных включающего языка.

! ! !

СОВЕТ. Claudio Valderrama С., который выполнил реализацию передачи через дескриптор, представил детальное описание этого процесса в статье «Using descriptors with UDFs» (Использование дескрипторов в UDF) на http:// www.cvalde.net/document/using_descriptors_with_udfs.htm.

. ! .

Параметры BLOB

Функции UDF, которые принимают параметры BLOB, требуют для обработки специальной структуры данных, BLOB передается по ссылке в управляющей структуре BLOB, описанной в разд. «Написание функций BLOB».

Спецификация возвращаемого значения

К типам данных возвращаемых значений применяются те же самые ограничения, что и к входным параметрам: типы данных включающего языка должны соответствовать типам данных Firebird. Например, объявление в С для функции FN_ABSO возвращает значение типа double, который корреспондирует с типом данных DOUBLE PRECISION в Firebird.

По умолчанию возвращаемые значения передаются по ссылке. Числовые значения могут также возвращаться по значению, хотя это и не очень хороший метод, и он не рекомендован. Для возврата числового параметра по значению включите необязательное ключевое слово BY VALUE после возвращаемого значения при объявлении UDF в базе данных.

Символьные типы данных

В UDF необходимо использовать типы данных включающего языка как для входных, так и для выходных значений. Firebird должен иметь возможность выполнить трансляцию между объявленным типом и типом данных SQL. В случае строк входной строкой UDF является тип CSTRING С заданной максимальной длиной в байтах, CSTRING используется для трансляции входных типов CHAR и VARCHAR В строку языка С, завершающуюся нулем, для обработки и для возвращения строки языка С переменной длины, завершающуюся нулем, для автоматического преобразования в Firebird в типы CHAR или VARCHAR. В случае других включающих языков убедитесь, что ваша функция возвращает строки, завершающиеся нулем.

При объявлении UDF, которая возвращает строку языка С, CHAR или VARCHAR, В объявление должно быть добавлено ключевое слово FREE_IT для освобождения памяти, используемой для возвращаемого значения, если она была выделена с помощью функции ib_util_malloc.

Соглашения о вызовах

Соглашение о вызовах определяет, как вызывается функция и как передаются параметры. Функция, получающая вызов, должна быть совместима с соглашением о вызове CDECL, используемым в Firebird. В функциях на языке С при использовании соглашения о вызове CDECL в объявление функции должно быть добавлено зарезервированное слово cdeci. В языке Pascal используйте cdeci.

Вот пример на языке С, где задается CDECL:

ISC_TIMESTAMP* cdeci addmonth(ISC_TIMESTAMP *preTime)

{

// здесь тело функции

}

Вопросы поточной обработки

В реализации Суперсервера в Firebird сервер выполняется как один многопоточный процесс. Это означает, что вам нужно проявлять некоторую осторожность при использовании способов выделения и освобождения памяти при кодировании UDF, а также при объявлении UDF. При использовании памяти в одном процессе в многопоточной архитектуре необходимо рассмотреть некоторые вопросы.

* Функции UDF должны выделять память с использованием функции ib_utii_ maiioc из библиотеки ib_util, а не с помощью статических массивов.

* Выделенная динамически память не освобождается автоматически, пока процесс не завершится. Вы должны использовать зарезервированное слово FREE IT при объявлении UDF в базе данных (DECLARE EXTERNAL FUNCTION).

* Статические переменные не сохраняются в потоке. Пользователи, выполняющие параллельно одну и ту же UDF, будут конкурировать, если они обратятся к одному пространству статической памяти. Неразумно использовать статические переменные, если вы не можете гарантировать, что только один пользователь в каждый конкретный момент времени будет обращаться к этой функции.

Если вы не можете исключить возвращаемый указатель на статические данные, вы не должны использовать FREE_IT.

Библиотека ib_util

Функция ib utii maiioc находится в вашем каталоге Firebird /lib, в совместно используемой библиотеке ib util.so в POSIX, ib_util.dll в Windows и ib utii.sl в HP-UX. Прототип функции для С и Pascal содержится в каталоге /include в файлах ib util.h и ib util.pas соответственно.

Указатели на переменные в Классическом сервере

При не поточном использовании Классического сервера вы можете возвращать глобальный указатель. В следующем примере функции FN LOWERO массив должен быть глобальным, чтобы исключить выход за пределы контекста:

char buffer[256];

char *fn_lower(char *ups) {

return (buffer); }

Создание UDF, защищенных от утечки памяти

При распределении памяти под возвращаемые значения для обеспечения потокобезопасности и переносимости следует использовать функцию ib_ut.ii_maiioc(). Вместе с ней нужно применять также ключевое слово FREE_IT В предложении RETURNS при объявлении функции, которая возвращает динамически создаваемые объекты.

В следующем примере сервер Firebird освободит буфер, если UDF была определена с зарезервированным словом FREE IT. Обратите внимание, что этот пример использует функцию Firebird ib_utii_maiioc() для выделения памяти:

char *fn_lower(char *ups) {

char *buffer = (char *) ib util_malloc(256);

return (buffer); }

Вот ее объявление:

DECLARE EXTERNAL FUNCTION lowercase VARCHAR (25 6)

RETURNS CSTRING(256) FREE_IT

ENTRY POINT ‘fn lower’ MODULE_NAME ‘ib_udf’;

! ! !

ПРИМЕЧАНИЕ. Память должна освобождаться той же библиотекой времени выполнения, которая выделяла эту память.

. ! .

Замечания по компиляции и компоновке

Когда модуль UDF готов, компилируйте его обычным образом в объектный или библиотечный формат.

Включите ibase.h или его эквивалент, если вы используете в нем объявления типов.

Если сборка выполняется статически, свяжите модуль с клиентской библиотекой Firebird, если вы обращаетесь к какой-либо функции библиотеки Firebird. Для Microsoft Visual C/C++ библиотеки fbclient ms.lib и ib_util_ms.lib могут быть найдены в каталоге Firebird /lib.

Изменение библиотеки функций

Для включения UDF в существующий модуль внешней функции добавьте файл, содержащий объектный код новой UDF, и перекомпилируйте как обычно. Некоторые платформы позволяют добавлять объектные файлы непосредственно в существующие библиотеки. Относительно подробностей посмотрите документацию по компилятору и редактору связей для конкретной платформы.

Для удаления функции следуйте инструкциям редактора связей по удалению объектов из библиотеки. Удаление функции из библиотеки не удаляет ее объявления из базы данных — используйте для этого DROP EXTERNAL FUNCTION.

Написание функции BLOB

Функции BLOB отличаются от других внешних функций, потому что им передаются указатели па управляющие структуры BLOB, а не на фактические данные. Функция не может открывать и закрывать BLOB, а вместо этого вызывает функции API для выполнения доступа к BLOB.

Создание управляющей структуры BLOB

Управляющая структура BLOB является структурой языка С, определенной в функциональном модуле в виде typedef. Программисты должны описать такую управляющую структуру на языке С, т. е. должны написать следующее:

typedef struct blob {

short (*blob_get_segment)();

isc_blob_handle blob_handle;

long number_segments;

long max_seglen;

long total_size;

void (*blob_put_segment)();

} *Blob;

Табл. 36.1 описывает поля в управляющей структуре BLOB.

Таблица 36.1. Поля в управляющей структуре BLOB^[145]

Поле	Описание
blob get segment	NULL, если внешняя функция не принимает BLOB в качестве входного аргумента. Иначе это поле является указателем на функцию, которая вызывается для чтения сегмента BLOB. Данная функция получает четыре аргумента: дескриптор BLOB, адрес буфера для сегмента BLOB, размер буфера и адрес переменной для хранения размера сегмента BLOB
blob handle	Требуемое поле. Это дескриптор BLOB, который уникально идентифицирует BLOB, передаваемый функции или возвращаемый функцией
number segments	NULL, если внешняя функция не принимает BLOB в качестве входного аргумента. В противном случае задает общее количество сегментов в BLOB
max seglen	NULL, если внешняя функция не принимает BLOB в качестве входного аргумента. В противном случае задает в байтах размер наибольшего передаваемого сегмента
total size	NULL, если внешняя функция не принимает BLOB в качестве входного аргумента. В противном случае задает в байтах фактический размер всего BLOB как единого целого
blob_put segment	NULL, если внешняя функция не принимает BLOB в качестве входного аргумента. В противном случае содержит указатель на функцию, которая вызывается для записи сегмента в BLOB. Эта функция принимает три аргумента: дескриптор BLOB, адрес буфера, содержащего данные для записи в BLOB, и размер в байтах записываемых данных

Объявление функции BLOB

Функция BLOB объявляется в базе данных с использованием DECLARE EXTERNAL FUNCTION с тем отличием, что тип ее объявления помещается перед ключевым словом RETURNS в качестве последнего аргумента в списке параметров вместо возвращаемого значения. Для аргумента RETURNS используйте ключевое слово PARAMETER и порядковый номер последнего параметра. Например, следующий оператор объявляет функцию BLOB, biob_pius_biob в модуле внешних функций с именем MyExtLib:

DECLARE EXTERNAL FUNCTION blob_plus_blob

Blob,

Blob

RETURNS PARAMETER 3

ENTRY_POINT ‘blob_concat’ MODULE_NAME ‘MyExtLib’;

Дополнительная информация

Учебник по написанию внешних функций доступен на сайте сообщества Firebird. Множество толковых статей можно найти в базах знаний и через поисковые машины.

Фильтры BLOB

В главе 12 мы коснулись специального типа внешних функций, которые могут быть использованы в Firebird для преобразования данных BLOB между двумя форматами, способными представлять совместимые данные. Фильтры BLOB являются определенными пользователем служебными подпрограммами на стороне сервера — фактически, специализированными UDF — способными получать данные BLOB В одном формате, преобразовывать их и возвращать в виде BLOB другого формата. Один раз скомпилированный и объявленный в базе данных, фильтр BLOB может быть использован в обычных операторах DML в клиентских приложениях, хранимых процедурах, триггерах и в isql.

В SQL Firebird фильтр BLOB распознается по его подтипу SUB_TYPE. Вы уже хорошо знакомы с двумя подтипами: 0 (для BLOB любого формата) и 1 (для неформатированного или минимально форматированного текста). Они предварительно определены внутренне вместе с множеством других, которые все являются положительными числами, их Firebird использует внутренне для метаданных и синтаксического разбора. Другие фильтры BLOB определяются пользователем, и могут иметь любое отрицательное число в качестве своего подтипа.

Сервер Firebird не имеет никакого «внутреннего знания» о том, что хранится (или может храниться) в BLOB заданного подтипа: ноль или меньше нуля. Задача приложения — обеспечить, чтобы вход и выход соответствовали целям подтипов, и какие фильтры BLOB будут написаны для их обработки.

Пары фильтров BLOB могут быть использованы для управления полезным диапазоном обычных преобразований данных, требуемых вашим приложениям, приведем примеры.

* Упаковка и распаковка данных. Один подтип хранит упакованные данные, в то время как другой обрабатывает их в распакованном виде. Фильтр BLOB может быть разработан для получения BLOB подтипа 1 (неизвестный формат) и преобразования его в сжатый формат (например, zip или гаг) и распаковки его для обработки как

SUB_TYPE 0.

* Вы можете использовать один подтип для хранения собственного кода приложения и другие для специфического системного кода и фильтр BLOB для добавления системных дополнений в собственный код, когда он требуется в запросе.

* Вы можете иметь подтип для хранения текста формата XML и фильтры BLOB для трансформации его в заданные выходные форматы — HTML, RTF, PDF, файлы UNIX, формат текстового процессора — для вывода в виде другого подтипа.

Возможности фильтров BLOB в Firebird позволяют уменьшить «разбухание», связанное с преобразованием данных для внешних процессоров. Преобразование кода в подпрограмме фильтра может быть настолько простым или сложным, насколько это требуется. Фильтры при необходимости могут вызывать другие модули, предоставляя в ваше распоряжение возможность включения существующих конвертирующих подпрограмм в ваши операции на сервере. Поскольку сам сервер имеет дело лишь с входом и выходом, в то время как ваш код фильтра поддерживается внешне, ваши фильтры могут быть изменены с учетом новейших технологий без воздействия на сервер.

Написание фильтров BLOB

Написание фильтров BLOB требует точно таких же усилий по управлению памятью и потоками, а также того же порядка действий, что и другие внешние функции, а именно:

1. Напишите фильтры и скомпилируйте их в объектные коды.

2. Создайте совместно используемую библиотеку фильтров (совместно используемый объект или DLL).

3. Сконфигурируйте сервер Firebird, чтобы он знал, где отыскать библиотеку во время выполнения.

4. Используйте DECLARE FILTER для объявления фильтров в базе данных.

5. Объявите столбцы в таблицах для хранения BLOB С тем подтипом, который «известен» фильтру.

6. Пишите приложения или модули PSQL, которым требуется фильтрация.

Объявление фильтров BLOB

На уровне базы данных фильтр распознается при объявлении метаданных с использованием следующего синтаксиса:

DECLARE FILTER <имя-фильтра>

INPUT_TYPE <подтип>

/* идентифицирует подтип конвертируемого объекта */

OUTPUT_TYPE <подтип>

/* идентифицирует подтип создаваемого объекта */

ENTRY_POINT ‘<имя-точки-входа>’

/* имя экспортируемой функции */

MODULE_NAME ‘<имя-внешней-библиотеки>’;

/* имя библиотеки фильтров BLOB */

Вызов фильтров BLOB

Преобразование из INPUT_TYPE В OTPUT_TYPE происходит автоматически, когда вызывается модуль MODULE_NAME с параметрами, которые были определены с корректными номерами подтипов.

Предположим, вы создаете библиотеку с именем filters.so или filters.dll, которая находится в допустимом для библиотек фильтров BLOB месте на сервере. В этой библиотеке у вас есть функция xmi_to_rtf, которая принимает BLOB, принимает текст, размеченный как XML, передает его программе, которая преобразует его в документ RTF, и, наконец, возвращает результат в новый BLOB. Вы сохраняете документы XML в BLOB SOB_TYPE -10, а тексты RTF в BLOB SUB_TYPE -15.

Во-первых, вы должны объявить фильтр BLOB В базе данных:

DECLARE FILTER XML2RTF /* ваш выбор имени */

INPUT_TYPE -10 /* текст, размеченный как XML */

OUTPUT_TYPE -15

/* текст RTF, форматированный по правилам компании */

ENTRY_POINT ‘xml_to_rtf’

/* точка входа для подпрограммы преобразования */

MODULE_NAME ‘filters’;

/* имя библиотеки фильтров BLOB */

Теперь в вашем SQL или PSQL все, что вам нужно для автоматического вызова преобразования, это переменная или столбец базы данных, определенный как BLOB SUB_TYPE -10, содержащий ваш замечательный, правильный документ XML, и переменная или столбец подтипа -15 для получения конвертированного документа.

! ! !

СОВЕТ. Включенные в набор Firebird специальные внутренние фильтры BLOB выполняют преобразование подтипа 0 в подтип 1 (текст) и подтипа 1 в подтип 0. Эти фильтры также могут преобразовывать данные BLOB любого подтипа Firebird — например, BLR=2 в подтип 1 (текст), что может быть полезным для получения содержимого столбца системной таблицы в приложении управления базой данных. В подтипе 1 блоки сегментированы с первого символа до символа начала новой строки, со следующего символа до другого символа начала строки и т.д.

. ! .

Инструменты для написания фильтров

API Firebird содержит группу макрофункций, начинающихся с isc_biob_fiiter_, которые являются «инструментом программиста» для написания фильтров BLOB. Документы API Guide и Embedded SQL Guide из набора документов Borland по InterBase версии 6 бета имеют разделы по написанию фильтров BLOB. Большое количество документов, описывающих как это делать, можно при минимальных затратах отыскать на сайтах сообщества.

API Firebird также содержит структуры — с их заголовками в ibase.h — для передачи и чтения информации относительно BLOB. Если у вас разыгралось любопытство, посмотрите дескрипторы BLOB и буфер параметров BLOB (BPB). Группа связанных

функций может быть использована в вашем коде фильтра BLOB, а также для прямого обращения к фильтрам BLOB из вашего кода приложения.

Модули интернациональных языков

Firebird поставляется с постоянно расширяющейся библиотекой поддержки интернациональных языков и последовательностей сортировки. Четыре «базовых» языка поставляются в библиотеке fbintl (для POSIX) или fbintl.dll (для Windows). Firebird отыскивает языковые библиотеки в каталоге инсталляции /intl.

Можно писать ваши собственные наборы символов и порядки сортировки и сделать так, чтобы сервер Firebird загружал их из библиотеки совместного использования, которая должна быть названа fbintl2, чтобы ее можно было распознать и загрузить. David Brookestone Schnepper, разработчик fbintl2, подготовил языковой пакет «сделай сам», свободно доступный на http://www.ibcolIate.com.

В Firebird 1.5 и выше также возможно реализовывать пользовательские наборы символов и порядки сортировки с использованием внешних функций. Поскольку комплект поставки fbintl2 включает ясные инструкции по каждому набору символов, он также может служить справочником, если вы планируете использовать внешние функции для реализации пользовательских наборов символов.

Конфигурирование внешних размещений

Существующий внешний код и данные, к которым обращается сервер, могут оказаться слабым местом в безопасности, если файловая система сервера неадекватно защищена от вторжений или хорошо видна из сети. Такие внешние фрагменты могут быть сделаны менее уязвимыми посредством конфигурирования ограничений при доступе к ним сервера Firebird. Возможность запрета доступа к нераспознаваемому размещению помогает в обеспечении безопасности файловой системы и сети.

! ! !

СОВЕТ. Конфигурируйте небольшое количество размещений для сокращения области поиска сервером и требуемого уровня управления доступом.

. ! .

Установки в файле конфигурации

Файл конфигурации Firebird, как обсуждалось ранее в этой главе, дает возможность выполнить установки по ограничению доступа к библиотекам внешних функций, модулей фильтров BLOB и К файлам данных, связанных с таблицами с помощью определения CREATE TABLE <имя-таблицы> EXTERNAL (внешние таблицы или EVT). Установки для Firebird 1.5 в файле firebird.conf отличаются от установок для Firebird 1.0.x в файле isc config (POSIX) или ibconfig (Windows).

Конфигурация версии 1.5 применима ко всем моделям сервера 1.5. Конфигурация для 1.0.x применима только к Суперсерверу.

UDFAccess

Версия 1.5 и выше, файл firebird.conf.

Этот параметр используется для ограничения доступа к библиотекам внешних функций и модулям фильтров BLOB, рассматриваемых как потенциальная мишень для злонамеренных атак. Вы можете выбрать один из трех уровней доступа сервера ко всем этим модулям. До версии 1.5 возможность хранения внешних модулей в различных местах файловой системы рассматривалась как преимущество. Сейчас рекомендуется, чтобы их хранение ограничивалось одним деревом или, в особо незащищенных ситуациях, лучше вообще их запрещать.

UDFAccess Может быть None, Restrict или Full.

* None запрещает любое использование определенных пользователем внешних библиотек. Это значение по умолчанию инсталляции большинства дистрибутивов.

* Restrict (установка по умолчанию) ограничивает размещение вызываемых внешних библиотек указанными размещениями файловой системы. По умолчанию поиск начинается в каталоге /UDF в вашем корневом каталоге Firebird. Для задания размещения библиотек внешних функций или модулей фильтров BLOB В другом месте файловой системы предоставьте список из одного или более каталогов, разделенных точкой с запятой (;), в которых могут размещаться эти модули, например:

POSIX: /db/extern;/mnt/extern Windows: С:ExternalModules

Относительные пути трактуются как пути относительно корневого каталога инсталляции Firebird. Например, в Windows, если инсталляция Firebird была в каталоге C:Program FilesFirebirdFirebird_1_5, то следующее значение будет ограничивать доступ сервера к внешним файлам, только если они будут размещаться в C:Program FilesFirebirdFirebird_1_5userdata ExternalModules:

UDFAccess = Restrict userdataExternalModules

* Full позволяет осуществлять доступ к внешним библиотекам в любом месте системы. Если задан доступ Full, то требуется включить полный путь в предложение

MODULE_NAME оператора DECLARE EXTERNAL FUNCTION, который объявляет функцию в базе данных. Подробности см. в разд. «Внешние функции (UDF)» главы 21.

external_function_directory

Версия 1.0.x, файл isc_config/ibconfig.

Этот параметр может быть использован в версии 1.0.x для задания произвольного количества размещений для библиотек внешних функций, фильтров BLOB И/ИЛИ модулей наборов символов. Если этот параметр конфигурации не присутствует, Firebird проверяет подкаталоги .Audf или ..intl в каталоге, который сервер распознает как корневой каталог инсталляции Firebird.

Вот несколько примеров:

external_function_directory <путь к каталогу, заключенный в кавычки>

external_function_directory «/opt/firebird/my_functions»

external_function_directory «/opt/extlibs/lang»

external_function_directory «d:udfdir»

ExternalFileAccess

Версия 1.5 и выше, файл firebird.conf.

Этот параметр предоставляет три уровня безопасности в отношении доступа к внешним файлам из таблиц базы данных. Значением является строка, которая может быть

None, Full или Restrict.

* None (значение по умолчанию) отключает любое использование внешних файлов вашим сервером.

* Restrict предоставляет возможность ограничить размещение внешних файлов для доступа из базы данных конкретными путями. Предоставьте список из одного или более путей, разделенных точкой с запятой (;), в которых могут храниться внешние файлы, например:

Unix: /db/extern;/mnt/extern

Windows: C:ExternalTables

Относительные пути трактуются как пути относительно каталога, который распознается запущенным сервером как корневой каталог инсталляции Firebird.

Например, в Windows, если корнем, который запущенный сервер распознает как корневой каталог инсталляции Firebird, является C:Program FilesFirebird, то следующее значение будет ограничивать сервер по доступу к внешним файлам, только если они будут размещаться на C:Program FilesFirebirduserdataExternalTables:

ExternalFileAccess = Restrict userdataExternalTables

Следующая запись в POSIX позволит осуществлять доступ только к файлам, находящимся в или ниже каталогов /exportdata и /importdata:

ExternalFileAccess = Restrict /exportdata;/importdata

* Full позволят осуществлять доступ к внешним файлам, находящимся в любом месте системы^[146].

Подробную информацию о внешних файлах см. в разд. «Использование внешних файлов в качестве таблиц» главы 16.

external_file_directory

Firebird 1.0.x, файл ibconfig.

Только в Windows используется для группирования внешних файлов в одной или нескольких ограниченных зонах. Нет ограничения на количество каталогов, которые могут быть представлены в списке поиска. Создавайте запись из одной строки для каждого каталога, как показано далее:

external_file_directory <путь к каталогу, заключенный в кавычки> external_file_directory «d: x-files»

Пора дальше

Последние главы описывают использование оставшихся инструментов командной строки, которые поставляются вместе с Firebird. Инструмент статистики gstat был описан ранее в главе 18, с инструментом управления доступом пользователя gsec вы познакомились в главе 35. Теперь рассмотрим интерактивную утилиту SQL isql.

ЧАСТЬ IX. Инструменты.

ГЛАВА 37. Интерактивный SQL (утилита isql).

Утилита isql, инсталлированная в каталоге /bin ниже вашего корневого каталога Firebird, предоставляет неграфический интерфейс для баз данных Firebird, который совместим со всеми серверными и клиентскими платформами.

isql принимает операторы DDL и DML, так же как и подмножество подобных SQL консольных команд, недоступных в DSQL. Утилита может быть использована как для создания и поддержания метаданных, так и для запросов к базе данных и изменения данных. Она включает некоторые инструменты администратора и режимы для выполнения прямых операций с базой данных из командной строки или из скриптов.

! ! !

ВНИМАНИЕ! Некоторые другие СУБД используют имя «isql» для своих интерактивных программ. Всегда запускайте программу isql Firebird из ее собственного каталога или задавайте абсолютный путь к файлу, если есть проблемы с вашим сервером.

. ! .

Интерактивный режим

Интерактивная утилита isql может быть запущена локально или с удаленного клиента.

* Для запуска isql с удаленного клиента всегда требуются имя пользователя и пароль.

* Если вы соединены локально, вы можете установить переменные операционной системы ISC_USER и ISC_PASSWORD и исключить необходимость вводить имя пользователя и пароль в командах. Подробнее об этих переменных см. в главе 3.

! ! !

ПРИМЕЧАНИЕ. При вызове интерактивной утилиты могут быть использованы некоторые дополнительные переключатели командной строки. Они представлены в табл. 37.1 в конце этой главы.

. ! .

Текстовый редактор по умолчанию

Некоторые команды isql обращаются к текстовому редактору системы по умолчанию.

* В UNIX, Linux и в некоторых других платформах POSIX редактор по умолчанию определяется одной из двух переменных окружения EDITOR и VISUAL. Значением по умолчанию при инсталляции обычно является vi, vim или emacs, но вы можете установить его в любой другой предпочитаемый консольный (но не X) текстовый редактор.

* В Windows похожая история. Редактор по умолчанию определяется переменной окружения EDITOR. В текущих версиях Windows это Notepad.exe, но вы можете установить его в любой текстовый редактор. В очень старых версиях Windows редактор по умолчанию, вероятно, был mep.exe или edit.exe.

Запуск isql

Для запуска isql откройте командную строку и перейдите в каталог Firebird /bin вашей инсталляции Firebird на сервере или клиенте. Наберите следующую команду в подсказке командной строки и нажмите клавишу <Enter>:

isql [имя-базы-данных] [-u[ser] <имя-пользователя> -pas[sword] <пароль>]

Имя базы данных не является обязательным. Если вы его указываете, то isql будет открывать соединение с указанной базой данных. Это должен быть либо полный путь к базе данных из того места, где вы находитесь, либо правильный алиас в версии 1.5 и более поздних.

Переключатели -user <имя-пользователя> и -password <пароль> являются необязательными, когда вы запускаете isql без указания связи с базой данных, и требуются, когда вы запускаете isql в удаленном режиме. Если переменные окружения ISC USER и ISC PASSWORD не установлены, имя пользователя и пароль требуются при старте isql локально.

Запуск программы в POSIX:

./isql

а в Windows:

isql

./isql -user TEMPDBA -password osoweary [в POSIX] isql -user TEMPDBA -password osoweary [в Windows]

запускается программа и сохраняются заданные имя пользователя и пароль без их идентификации.

isql hotchicken:/data/mydatabase.fdb -user TEMPDBA -password osoweary

Указанная команда запускает программу на клиенте Windows и соединяется с базой данных на сервере POSIX, предоставляя верные на сервере имя пользователя и пароль.

./isql /data/mydatabase.fdb

запускает локально программу на сервере Linux и соединяется с базой данных в предположении, что переменные окружения ISC_USER и ISC_PASSWORD установлены и доступны вашему пользовательскому профилю пользователя в Linux.

Если вы подключились к базе данных при запуске isql, вы увидите консоль, похожую на рис. 37.1. Конкретный вид окна командной строки зависит от операционной системы. Командная строка isql одинакова для всех платформ.

Рис. 37.1. Консоль, отображаемая при запуске isql с подключением к базе данных

Если вы не ввели путь к базе данных или имя пользователя и пароль не определены на сервере, вы увидите нечто, похожее на рис. 37.2.

Рис. 37.2. Консоль, отображаемая при запуске isql без подключения к базе данных

Если были ошибки в командной строке или возникли проблемы с идентификацией пользователя, вы можете также увидеть сообщения об ошибке. Если вы видите подсказку SDQ>, значит вы находитесь в командной строке isql и можете из нее соединяться с базой данных.

Соединение с базой данных

Для соединения с базой данных из подсказки SQL> командной строки isql используйте следующий пример в качестве образца синтаксиса. Обратите внимание, что синтаксис внутри командной строки isql отличается от синтаксиса, используемого при передаче параметров соединения и системной командной строки.

CONNECT ‘HOTCHICKEN:L:DATAEXAMPLESEMPLOYEE.FDB’

USER ‘SYSDBA’ PASSWORD ‘masterkey’;

соединяет с удаленным или локальным сервером с именем HOTCHICKEN.

CONNECT ‘L:DATAEXAMPLESEMPLOYEE.FDB’;

соединяет с локальным сервером, на котором isql уже знает ваше имя пользователя и пароль — либо потому что вы правильно ввели их при запуске isql, либо потому что isql выполняется в командной строке, которая может видеть переменные окружения ISC_USER и ISC_PASSWORD.

CONNECT ‘HOTCHICKEN:EMP3’ USER ‘SYSDBA’ PASSWORD ‘masterkey’;

эквивалентно первому примеру в Firebird версии 1.5 и выше; при этом используется алиас, хранящийся в файле aliases.conf на сервере, который указывает путь.

CONNECT ‘L:/DATA/EXAMPLES/EMPLOYEE.FDB’;

эквивалентно второму примеру. В isql наклонная черта может быть прямой и обратной.

Имя сервера и путь

В Windows не путайте имена серверов и имена совместно используемых дисков. Сеть клиент-сервер не распознает разделяемые диски и каталоги (mapped drive, shared folder). Идентификатор диска всегда должен указывать на фактическую букву жесткого диска или раздела на серверной машине.

Идентификация пользователя

Независимо от того, соединились ли вы из командной строки или сделали это внутри командной строки isql, идентификация пользователя будет ошибочной, если сервер не распознает имя пользователя или пароль. Например, на рис. 37.3 показано, что вы увидите, если оператор CONNECT будет ошибочным.

Рис. 37.3. Ошибочная идентификация пользователя

Если такое произошло, дважды проверьте, правильно ли вы задали имя пользователя и пароль, и в правильном ли регистре введен пароль. Пароль чувствителен к регистру, а имя пользователя нет.

Символ терминатора

Терминатором оператора по умолчанию является точка с запятой (;), которая используется во всех примерах в этой главе. Вы можете изменить этот терминатор любым другим символом или группой символов посредством команды SET TERM[INATOR]. Например, чтобы заменить его на «!!», используйте следующий оператор:

SQL> SET TERM !!;

SQL>

Продолжение строки подсказки

Если вы нажмете клавишу <Enter>, забыв завершить оператор терминатором, вы увидите продолжение подсказки CON> вместо подсказки isql SQL>:

SQL> SHOW DATABASE

CON>

Если это было ошибкой, просто наберите терминатор и опять нажмите клавишу <Enter>. Причем вы можете использовать эту возможность, чтобы сделать ваш текст более читаемым, например:

SQL> CREATE TABLE ATABLE (

CON> ID INTEGER NOT NOLL,

CON> DATA VARCHAR(20),

CON> DATE_ENTERED DATE

CON> DEFAULT CURRENT_DATE

CON> );

SQL>

! ! !

СОВЕТ. Одна из причин применения возможности продолжения — это то, что вы можете использовать команду OUTPUT для помещения введенного вами в isql текста в файл. Поскольку вывод сохраняется точно в таком же виде, как вы вводите данные, все ваши пробельные отступы будут сохранены. Многие пользователи Firebird используют isql в качестве единственного редактора скриптов!

. ! .

Транзакции в isql

Управление транзакциями в isql отличается в зависимости от того, вводите ли вы оператор DDL, команду SHOW или другие виды операторов.

Когда isql стартует, она запускает транзакцию с уровнем изоляции SNAPSHOT (параллельный) с установкой разрешения блокировок WAIT. Если вы выполняете не операторы DDL и не команды SHOW, транзакция продолжает оставаться текущей, пока вы не выдадите оператор COMMIT или ROLLBACK.

Вы можете стартовать явную транзакцию, подтвердив текущую транзакцию, и выдав оператор SET TRANSACTION. Например, для старта транзакции READ COMMITTED NO WAIT введите:

SQL> COMMIT;

SQL> SET TRANSACTION

CON> NO WAIT READ COMMITTED;

При завершении вашей задачи просто выдайте как обычно оператор COMMIT. Следующий оператор вернет систему в конфигурацию по умолчанию.

Операторы DDL

Каждый раз, когда вы выдаете оператор DDL, isql стартует для него специальную транзакцию и немедленно ее подтверждает после того, как вы нажимаете клавишу <Enter>. Сразу после этого стартует новая транзакция. Вы можете изменить автоматическое поведение, выдав команду SET AUTODDL OFF из подсказки SQL до начала выполнения ваших операторов DDL:

SQL> SET AUTODDL OFF;

Чтобы опять включить режим автоматического подтверждения операторов DDL, введите:

SQL> SET AUTODDL ON;

Для переключения между режимами включено/выключено существует сокращенная версия команды:

SQL> SET AUTO;

Команды SHOW

Команды SHOW в isql запрашивают данные из системных таблиц. Когда вы вызываете команду SHOW, isql подтверждает существующую транзакцию и стартует новую с уровнем изоляции READ COMMITTED. Это гарантирует, что вы всегда видите самые последние изменения метаданных, как только они будут изменены.

Поиск в буфере строк

Начиная с версии 1.5 и выше, isql позволяет вам отыскивать строки в буфере способом, похожим на возможность readiine на платформах POSIX. Используйте клавиши <Т> (стрелка вверх) и <i> (стрелка вниз) для «прокручивания» буфера isql по одной строке за раз для поиска копий строк, которые вы вводили ранее.

Использование предупреждений

По умолчанию isql выдает предупреждения при некоторых условиях, например:

* операторы, не выполняющие действий;

* двусмысленная спецификация соединений в Firebird 1.0.x (в версии 1.5 и выше это вызовет исключение);

* выражения, которые дадут различные результаты в различных версиях Firebird;

* вызовы API, которые будут изменены в будущих версиях;

* когда база данных переведена в состояние SHUTDOWN.

Для переключения режима выдачи предупреждений в процессе выполнения сессии интерактивной isql используйте SET WARNINGS или сокращенный вариант SET WNG.

Обработка исключений

Ошибки в isql обрабатываются тем же образом, что и приложении DSQL. isql отображает сообщение об ошибке, содержащее переменную SQLCODE и текст сообщения из массива состояния Firebird, как показано на рис. 37.4.

Рис. 37.4. Пример сообщения об ошибке в isql

Ошибки SQL со значением SQLCODE меньше нуля означают, что оператор не был выполнен. Все они представлены в приложении 10. Вы можете также увидеть одно из предупреждений SQL или информационное сообщение, а именно:

* 0: SUCCESS (успешное выполнение);

* +1-99-. SQLWARNING (системное предупреждение или информационное сообщение);

* +100 NOT FOUND (указывает, что указанные строки не найдены или достигнут «конец файла»; т. е. определен конец текущего активного набора строк).

Установка в isql диалекта

Если вы запустили isql и соединились с базой данных без указания диалекта, утилита принимает диалект базы данных.

Вы можете установить диалект для isql несколькими способами.

* При запуске isql:

[bin] isql -s n

где n- число 1, 2 или 3. Если вы зададите диалект этим способом, isql сохранит данный диалект после соединения, если только вы явно его не измените.

* В сессии isql или в скрипте SQL:

SET SQL DIALECT N;

Утилита продолжит работать с этим диалектом, пока он не будет явно изменен. Диалект не может быть установлен как параметр оператора CREATE DATABASE.

! ! !

ВНИМАНИЕ! Когда вы создаете базу данных интерактивно с использованием isql, база данных будет в том диалекте, который в настоящий момент существует у isql во время выдачи оператора CREATE DATABASE. Вам нужно будет учесть это, если у вас была перед этим открыта база данных с диалектом 1, потому что isql останется в диалекте 1 и после отключения от базы данных с диалектом 1.

. ! .

Воздействие диалектов

Эффекты команд могут иметь некоторые изменения в зависимости от диалекта.

* Клиент диалекта 1 обрабатывает все команды в соответствии с ожиданием языка InterBase 5 и синтаксиса с некоторыми изменениями. Например, если вы создаете таблицу, в которой задается столбец типа DATE, вы увидите информационное сообщение, говорящее, что «DATE datatype is now called TIMESTAMP» (Тип данных DATE сейчас называется TIMESTAMP).

* В клиенте диалекта 2 элементы, имеющие различную интерпретацию в диалектах 1 и 3, отмечаются предупреждениями или ошибками для помощи в миграции баз данных в диалект 3.

* Клиент диалекта 3 анализирует все операторы в соответствии с родной семантикой SQL Firebird: кавычки используются для идентификаторов с ограничителями и не распознаются как ограничители строк, тип данных DATE содержит только дату, а истинные числа (числа с фиксированной точкой) с точностью больше 9 хранятся как BIGINT (NUMERIC(18, О) в Firebird 1.0.x).

Интерактивные команды

Вы можете интерактивно вводить три вида команд или операторов в подсказке SQL>.

* Операторы SQL определения данных (DDL), такие как CREATE, ALTER, DROP и REVOKE. Эти операторы создают, изменяют или удаляют метаданные и объекты или управляют полномочиями доступа пользователя (привилегиями) к базе данных.

* Операторы SQL манипулирования данными (DML), такие как SELECT, INSERT, UPDATE и DELETE. Выход операторов SELECT может быть отображен или направлен в файл (см. команду OUTPUT).

* Команды isql, которые разделяются на три основные категории:

• общие команды (например, команды чтения входного файла, записи в выходной файл или завершения сессии isql);

• команды SHOW (для отображения метаданных и другой информации базы данных);

• команды SET (для изменения окружения isql).

Создание и изменение объектов базы данных

В сессии isql вы можете выдавать операторы DDL один за другим для создания (CREATE) или удаления (DROP) баз данных, доменов, генераторов, таблиц, индексов, триггеров и хранимых процедур. Вместе с исключениями генераторов вы также можете выдавать операторы ALTER для любого из этих объектов.

Поскольку можно создавать базу данных, выдавая и подтверждая серии операторов DDL в процессе сессии интерактивной isql, такой подход является специализированным. Он не позволяет документировать процесс и оставляет дыры в процессе отладки и тестирования.

Скрипты

Очень хорошей практикой является использование скриптов для создания базы данных и ее объектов. Скрипт для создания и изменения объектов базы данных иногда называют скриптом схемы, файлом определения данных или просто DDL-скриптом. Тема использования скриптов схемы рассматривается в деталях в главе 14.

Скрипты по изменению базы данных дают вам постоянную фиксацию эволюции вашей базы данных и возможность отслеживать и отменять любые неразумные изменения. Утилита isql может создавать скрипт в процессе интерактивной сессии, передавая ваш ввод с клавиатуры в указанный файл. Чтобы узнать, как это сделать, прочтите примечания к команде OUTPUT в следующем разделе.

Вы можете запустить скрипт, созданный в isql или в любом другом текстовом редакторе, посредством команды INPUT. Она может быть также использована внутри скрипта для создания вложенных скриптов.

Общие команды isql

Общие команды isql выполняют множество полезных задач, включая чтение, запись и выполнение скриптов схемы, а также выполнение команд командной строки. Командами являются BLOBDUMP, BLOBVIEW, EDIT, EXIT, HELP, INPUT, OUTPUT, QUIT и SHELL.

BLOBDUMP сохраняет данные BLOB В указанном файле:

BLOBDUMP идентификатор-BLOB имя-файла;

где идентификатор-BLOB- идентификатор, содержащий два шестнадцатеричных числа, разделенных двоеточием (:). Первое число является идентификатором таблицы, содержащей столбец BLOB. Второе — последовательный номер объекта. Для получения этого идентификатора выдайте любой оператор SELECT, который выбирает столбец BLOB. Выход покажет шестнадцатеричный идентификатор BLOB выше или на месте столбца BLOB в зависимости от того, установлен ли SET [DISPLAY] В ON или OFF.

имя-файла — полное имя файловой системы того файла, который получает данные.

Пример:

SQL> BLOBDOMP 32:d48 IMAGE.JPG ;

BLOBVXEW отображает данные BLOB В текстовом редакторе по умолчанию.

BLOBVIEW идентификатор-BLOB ;

где идентификатор-BLOB- идентификатор, содержащий два шестнадцатеричных числа, разделенных двоеточием (:). См. описание BLOBDUMP для определения идентификатора BLOB, который вы ищите. В текущей версии BLOBVIEW не поддерживает редактирования BLOB В режиме онлайн. Это может быть добавлено в будущие реализации.

Пример:

SQL> BLOBVIEW 85:7 ;

Замечание по ошибке: BLOBVIEW может вернуть ошибку «Invalid transaction handle» (Неверный дескриптор транзакции) после закрытия редактора. Для исправления ситуации запустите транзакцию вручную с помощью:

SQL> SET TRANSACTION;

EDIT позволяет отредактировать и заново выполнить предыдущую команду isql или пакет команд в исходном файле.

SQL> EDIT [имя-файла] ;

где имя-файла- (необязательно) полностью заданное имя файла для редактирования в файловой системе.

Пример:

SQL> EDIT /usr/mystuff/batch.sql

Команда EDIT также может быть использована для открытия предыдущих операторов в редакторе:

SQL> SELECT EMP_CODE, EMP_NAME FROM EMPLOYEE ; SQL> EDIT ;

Нажмите клавишу <Enter> для отображения «прокрутки» вашей сессии isql в текстовом редакторе ASCII по умолчанию в вашей системе. Отредактируйте, при желании сохраните и выйдите. Отредактированный пакет команд будет заново выполнен в вашей командной строке isql после того, как вы выйдете из редактора.

EXIT подтверждает текущую транзакцию без подсказки, закрывает базу данных и завершает сессию isql. Если вам нужно выполнить откат, а не подтверждение транзакции, используйте QUIT.

SQL> EXIT ;

EXIT не принимает никаких аргументов.

HELP отображает список команд isql с их описанием. Вы можете объединить эту команду с OUTPUT для вывода списка в файл.

SQL> HELP ;

Пример:

SQL> OUTPUT HELPLIST.TXT ; SQL> HELP ;

SQL> OUTPUT ; /* переключает вывод опять на монитор */

HELP не принимает никаких аргументов.

INPUT читает и выполняет блок команд из указанного текстового файла (скрипта SQL). Входные файлы могут содержать другие команды INPUT, предоставляя таким образом возможность проектирования цепочного или структурированного набора скриптов DDL. Для создания скриптов используйте текстовый редактор или создавайте их интерактивно посредством команд OUTPUT или EDIT.

SQL> INPUT имя-файла ;

где имя-файла — полностью заданное имя файла, содержащего операторы и команды SQL.

Пример:

SQL> INPUT /data/schemascripts/myscript.sql ;

В скрипте:

CREATE EXCEPTION Е010 ‘This is an exception.’; COMMIT;

— TABLE DEFINITIONS

INPUT ‘/data/schemascripts/tabledefs.sql’; — CONSTRAINT DEFINITIONS

INPUT

‘data/schemascripts/constraintdefs.sql’;

OUTPUT перенаправляет выходные данные в файл на диске или (назад) на стандартное устройство вывода (монитор). Используйте команды SET ECHO для включения или исключения из вывода команд:

* SET ECHO ON — для вывода команд и данных;

* SET ECHO OFF — для вывода только данных.

SQL> OUTPUT [имя-файла];

где имя-файла — полностью заданное имя файла, содержащего операторы и команды SQL. Если имя файла не указано, результаты появятся на стандартном выводе, на мониторе (т. е. вывод в файл отключен).

Пример:

SQL> OUTPUT d:dataemployees.dta ;

SQL> SELECT EMP_NO, EMP_NftME FROM EMPLOYEE ;

/* вывод отправляется в файл */

SQL> OUTPUT ; /* переключает вывод опять на монитор */

! ! !

СОВЕТ. Если вы используете OUTPUT для создания скриптов, то может понадобиться их отредактировать, чтобы удалить случайные интерактивные команды isql. Однако, когда вы направляете этот вывод в isql, используя INPUT, isql обычно просто игнорирует отраженные интерактивные команды.

. ! .

QUIT отменяет текущую транзакцию и закрывает окно isql.

SQL> QUIT ;

QUIT не принимает аргументов. Если вам нужно подтвердить транзакцию вместо ее отката, используйте EXIT.

SHELL предоставляет временный доступ к окну командной строки без подтверждения или отката любой транзакции.

SQL> SHELL [команда операционной системы] ;

где команда операционной системы- (необязательно) команда или вызов, допустимый в командной строке, из которой была запущена isql. Команда будет выполнена, а управление возвращено isql. Если команда не указана, isql открывает интерактивную сессию в командной строке. Ввод EXIT возвращает управление isql.

Пример:

SQL> SHELL dir /mydir | more ;

Этот пример отобразит содержимое каталога /mydir и возвратит управление isql, когда отображение будет завершено или завершится утилита more при нажатии комбинации клавиш <Ctrl>+<C>.

Команды SHOW

Команды SHOW используются для отображения метаданных, включая таблицы, индексы, процедуры, триггеры и привилегии. Они могут отображать список имен всех объектов указанного типа или предоставлять детальную информацию о конкретном объекте, заданном в команде.

Команды SHOW являются (приблизительным) интерактивным эквивалентом командной строки -extract, -x или -а режим (см. разд. «Извлечение метаданных»). Однако, хотя вы можете использовать команду OUTPUT для пересылки выхода команд SHOW в файл, сохраненный текст не будет готов к использованию в качестве скрипта схемы без редактирования. Используйте опции командной строки, если получение скрипта схемы является вашей целью.

Каждая команда SHOW выполняется в своей собственной транзакции READ COMMITTED, гарантируя, что каждый вызов вернет самый последний вид состояния базы данных.

SHOW CHECK отображает имена и тексты всех определенных пользователем ограничений CHECK, заданных для указанной таблицы.

SQL> SHOW CHECK имя-таблицы ;

где имя-таблицы- имя таблицы, которая существует в подключенной базе данных. Пример:

SQL> SHOW CHECK JOB ;

CONSTRAINT INTEG_12

CHECK (min_salary < max_salary)

SHOW DATABASE отображает информацию о подключенной базе данных (имя файла, размер и количество выделенных страниц, интервал очистки, номера транзакций, статус Forced Writes, набор символов по умолчанию), SHOW DB является сокращенной версией этой команды.

SQL> SHOW DATABASE | DB ;

SHOW DATABASE не принимает аргументов. На рис. 37.5 показан результат, который вы можете ожидать от команды SHOW DATABASE.

! ! !

СОВЕТ. Для получения информации о версии и структуре на диске (ODS) используйте SHOW VERSION.

. ! .

SHOW DCMAXN[S] отображает информацию домена.

SQL> SHOW { DOMAINS | DOMAIN имя };

DOMAINS — отображает список имен всех доменов, объявленных в базе данных. DOMAIN ИМЯ- отображает определение одного указанного домена.

Рис. 37.5. Результат выполнения SHOW DATABASE

Примеры:

SQL> SHOW DOMAINS ;

D_CURRENCY D_NOTES

D_BOOLEAN D_PHONEFAX

. . .

SQL> SHOW DOMAIN D_BOOLEAN ;

D_BOOLEAN SMALLINT NOT NULL

DEFAULT 0

CHECK(VALUE IN (0,1)

SHOW EXCEPTION[S] отображает информацию исключения.

SQL> SHOW { EXCEPTIONS | EXCEPTION имя };

EXCEPTIONS- отображает список имен и текстов всех исключений, объявленных в базе данных.

EXCEPTION имя — отображает текст одного указанного исключения. Примеры:

SQL> SHOW EXCEPTIONS ; Exception Name Used by, Type

BAD_WIZ_TYPE UPD_FAVEFOOD, Stored procedure Invalid Wiz type, check CAPS LOCK

SQL> SHOW EXCEPTION BAD_WIZ_TYPE ; Exception Name Used by, Type

BAD_WIZ_TYPE UPD_FAVEFOOD, Stored procedure Invalid Wiz type, check CAPS LOCK

SHOW FUNCTION[s] отображает информацию о внешних функциях, объявленных в подключенной базе данных.

SQL> SHOW { FUNCTIONS | FUNCTION имя };

FUNCTIONS- отображает список имен всех внешних функций, объявленных в базе данных.

FUNCTION ИМЯ- отображает объявление указанной внешней функции. Примеры:

SQL> SHOW FUNCTIONS ;

ABS MAXNUM

LOWER SUBSTRLEN

. . .

SQL> SHOW FUNCTION maxnum ;

Function MAXNUM:

Function library is /usr/firebird/udf/ib_udf.so

Entry point is FN_MAX

Returns BY VALUE DOUBLE PRECISION

Argument 1: DOUBLE PRECISION

Argument 2: DOUBLE PRECISION

SHOW GENERATOR[S] отображает информацию о генераторах, объявленных в подключенной базе данных.

SQL> SHOW { GENERATORS | GENERATOR имя };

GENERATORS — отображает список имен всех генераторов, объявленных в базе данных вместе с их текущими значениями.

GENERATOR имя- отображает объявление указанного генератора вместе с его текущим значением.

Примеры:

. . .

SQL> SHOW GENERATORS ;

Generator GEN_EMPNO, Next value: 1234

Generator GEN_JOBNO, Next value: 56789

Generator GEN_ORDNO, Next value: 98765

. . .

SQL> SHOW GENERATOR gen_ordno ;

Generator GEN_ORDNO, Next value: 98765

SHOW GRANT отображает информацию привилегий и ролей по отношению к указанному объекту в подключенной базе данных или отображает членство пользователей в роли.

SQL> SHOW GRANT { объект имя-роли } ;

где объект- имя существующей таблицы, просмотра или процедуры в текущей базе данных.

имя-роли- имя существующей роли в текущей базе данных. Используйте SHOW ROLE для получения списка всех ролей, определенных в этой базе данных.

Примеры:

SQL> SHOW GRANT JOB ;

GRANT SELECT ON JOB TO ALL

GRANT DELETE, INSERT, SELECT, UPDATE ON JOB TO MANAGER

SQL> SHOW GRANT DO_THIS ;

GRANT DO THIS TO MAGICIAN

SHOW INDEX (SHOW INDICES) отображает информацию об указанном индексе, об индексах для указанной таблицы или обо всех индексах для всех таблиц в подключенной базе данных. Эта команда может быть сокращена: SHOW IND.

SQL> SHOW {INDICES | INDEX { индекс таблица }};

где индекс- имя существующего индекса в текущей базе данных. таблица — имя существующей таблицы в текущей базе данных. Примеры:

. . .

SQL> SHOW INDEX ;

RDB$PRIMARY1 UNIQUE INDEX ON COUNTRY(COUNTRY)

CUSTNAMEX INDEX ON CUSTOMER(CUSTOMER)

CUSTREGION INDEX ON CUSTOMER(COUNTRY, CITY)

RDB$FOREIGN23 INDEX ON CUSTOMER(COUNTRY)

. . .

SQL> SHOW IND COUNTRY ;

RDB$PRIMARY20 UNIQUE INDEX ON COUNTRY(COSTNO)

CUSTNAMEX INDEX ON CUSTOMER(CUSTOMER)

! ! !

ПРИМЕЧАНИЕ. Для получения информации о текущем состоянии индексов в базе данных используйте gstat -i. Применение утилиты gstat обсуждалось в конце главы 18.

. ! .

SHOW PROCEDURE[S] отображает все процедуры в подключенной базе данных с их зависимостями или отображает текст указанной процедуры с объявлениями и типами (входной/выходной) каждого аргумента. Команда может иметь сокращенный вид SHOW PROC.

SQL> SHOW {PROCEDURES | PROCEDURE имя } ;

PROCEDURES — отображает список имен всех процедур вместе с их зависимостями.

PROCEDURE имя- для указанной процедуры отображает исходный текст, зависимости и аргументы.

Примеры:

SQL> SHOW PROCEDURES ;

Procedure Name	Dependency	Type
=======	=======	=======
ADD EMP PROJ	EMPLOYEE PROJECT	Table
	UNKNOWN_EMP_ID	Exception
DELETE EMPLOYEE	DEPARTMENT	Table
	EMPLOYEE	Table
	EMPLOYEE PROJECT	Table

SQL> SHOW PROC ADD_EMP_PROJ ;

Procedure text:

BEGIN

INSERT INTO EMPLOYEE_PROJECT (

EMP_NO, PROJ_ID) VALUES (

:emp_no, :proj_id) ;

WHEN SQLCODE -530 DO

EXCEPTION UNKNOWN_EMP_ID;

END

RETURN ;

END

Parameters:

EMP_NO INPUT SMALLINT

PROJ_ID INPUT CHAR(5)

SHOW ROLE [s] отображает имена ролей SQL в подключенной базе данных.

SQL> SHOW ROLES ;

SHOW ROLES не принимает аргументов. Примеры:

SQL> SHOW ROLES ; MAGICIAN MANAGER PARIAH SLEEPER

SHOW GRANT имя роли используется для отображения членства пользователей в ролях.

SHOW SQL DIALECT отображает диалекты SQL клиента и подключенной базы данных, если такая есть.

SQL> SHOW SQL DIALECT;

Пример:

SQL> SHOW SQL DIALECT;

Client SQL dialect is set: 3 and database SQL dialect is: 3

SHOW SYSTEM отображает имена системных таблиц и системных просмотров в подключенной базе данных. Команда имеет сокращение SHOW SYS.

SQL> SHOW SYS [ TABLES ] ;

Команда не принимает аргументов, TABLES является необязательным ключевым словом, которое не влияет на поведение команды.

Примеры:

SQL> SHOW SYS ;

RDB$CHARACTER_SETS RDB$CHECK_CONSTRAINTS RDB S COLLATION S RDB $ DATABASE

Подробную информацию о системных таблицах см. в приложении 9.

SHOW TABLE[S] отображает все таблицы или просмотры либо информацию об указанной таблице или просмотре.

SQL> SHOW { TABLES | TABLE имя };

SHOW TABLES — отображает список имен всех таблиц и просмотров в алфавитном порядке.

SHOW TABLE имя- показывает подробности указанной таблицы или просмотра. Если объект является таблицей, вывод содержит имена столбцов и их определение, PRIMARY KEY, FOREIGN KEY, ограничения CHECK и триггеры. Если объект является просмотром, то вывод содержит имена столбцов и оператор SELECT, на котором основывается просмотр.

Примеры:

SQL> SHOW TABLES ; COUNTRY CUSTOMER

DEPARTMENT EMPLOYEE EMPLOYEE?PROJECT JOB

SQL> SHOW TABLE COUNTRY ; COUNTRY COUNTRYNAME VARCHAR (15) NOT NULL CURRENCY VARCHAR(10) NOT NULL PRIMARY KEY (COUNTRY)

См. также SHOW VIEWS позже в этой главе.

SHOW TRiGGER[S] отображает все триггеры, определенные в базе данных вместе с их таблицами, или для указанного триггера отображает его последовательный номер, тип, статус активности (активен/не активен) и определение PSQL. Сокращенный вариант команды SHOW TRIG.

SQL> SHOW {TRIGGERS | TRIGGER имя } ;

SHOW TRIGGERS — отображает список имен всех таблиц вместе с именами их триггеров в алфавитном порядке.

SHOW TRIGGER имя- для заданного триггера указывает таблицу, к которой он принадлежит, отображает параметры заголовка, статус активности и исходный код PSQL тела триггера.

Примеры:

SQL> SHOW TRIGGERS ;

Table name Trigger name

========== ==========

EMPLOYEE SET_EMP_NO

EMPLOYEE SAVE_SALARY_CHANGE

CUSTOMER SET_CUST_NO

SALES PQST_NEW_ORDER

SQL> SHOW TRIG SET_CUST_NO ;

Trigger:

SET_CUST_NO, Sequence: 0, Type: BEFORE INSERT, Active

BEGIN

new.custno = gen_id (cust_no_gen, 1);

END

SHOW VERSION отображает информацию о программной версии isql и серверной программы Firebird, а также номер структуры на диске (ODS) подключенной базы данных. Сокращенный вариант команды SHOW VER.

SQL> SHOW VERSION ;

Команда не принимает аргументов.

Пример для сервера с именем dev с запушенным Firebird 1.5 под Windows 2000:

SQL> SHOW VER ; —

ISQL Version: WI-V1.5.0.4306 Firebird 1.5 Firebird/x86/Windows NT (access method), version «WI-V1.5.0.4306 Firebird 1.5» Firebird/x86/Windows NT (remote server), version «WI-V1.5.0.4306 Firebird 1.5/tcp (dev)/P10» Firebird/x86/Windows NT (remote interface), version «WI-V1.5.0.4306 Firebird 1.5/tcp (dev)/Р10» on disk structure version 10.1

SHOW VXEW[S] отображает все просмотры или информацию об указанном просмотре. (См. также SHOW TABLES.)

SQL> SHOW { VIEWS | VIEW имя } ;

SHOW VIEWS — отображает список имен всех просмотров в алфавитном порядке.

SHOW VIEW ИМЯ- отображает имена столбцов и оператор SELECT, на котором основан просмотр.

Пример:

SQL> SHOW VIEWS ;

PHONE_LIST CUSTOMER

. . .

SQL> SHOW VIEW PHONE_LIST;

EMP_NO (EMPNO) SMALLINT Not Null

FIRST_NAME (FIRSTNAME) VARCHAR(15) Not Null

LAST_NAME (LASTNAME) VARCHAR(20) Not Null

PHONE_EXT VARCHAR(4) Nullable

LOCATION VARCHAR(15) Nullable

PHONE_NO (PHONENUMBER) VARCHAR(20) Nullable

View Source:

=============

SELECT

emp_no, first_name, last_name, phone_ext, location, phone_no FROM employee, department

WHERE employee.dept_no = department.dept_no

Команды SET

Команды SET позволяют просматривать и изменять некоторые вещи, связанные со средой isql. Отдельные из них доступны в скриптах.

SET AUTODDL задает, будут ли операторы DLL подтверждаться автоматически после их выполнения или будут подтверждаться после явного выполнения COMMIT. Оператор доступен в скриптах.

SQL> SET AUTODDL [ON | OFF] ;

/* значение по умолчанию ON */

где ON — включает автоматическое подтверждение. OFF- отключает автоматическое подтверждение.

SET AUTO (без аргументов) просто переключает AUTODDL между включено и выключено.

Пример:

. . .

SQL> SET AUTODDL OFF ;

SQL> CREATE TABLE WIZZO (x integer, у integer) ; SQL> ROLLBACK; /* таблица WIZZO не создана */

. . .

SQL>SET AUTO ON ;

SQL> CREATE TABLE WIZZO (x integer, у integer) ; SQL> /* таблица WIZZO создана */

SET HLOBDISPLAY задает необходимость отображения подтипа BLOB и отображения данных BLOB. Сокращенной версией этой команды является SET BLOB.

SQL> SET BLOBDISPLAY [ n | ALL |OFF ];

n — отображать BLOB заданного подтипа. Значение по умолчанию n = 1 (текст). Положительные числа определены в системе; отрицательные числа определяются пользователем.

ALL — отображать данные BLOB любого подтипа.

OFF- отключает отображение данных BLOB. Вывод показывает только идентификатор BLOB (Blob ID- два шестнадцатеричных числа, разделенных двоеточием). Первое число является идентификатором таблицы, содержащей столбец BLOB. Второе является последовательным номером реализации и идентифицирует данные BLOB.

Пример:

. . .

SQL> SET BLOBDISPLAY OFF ;

SQL> SELECT PROJ_NAME, PROJ_DESC FROM PROJECT ;

SQL> /* строки показывают значения PROJ_NAME и Blob ID */

. . .

SQL>SET BLOB 1 ;

SQL> SELECT PROJ_NAME, PROJ_DESC FROM PROJECT ;

SQL> /* строки показывают значения PROJ_NAME и Blob_ID, */

SQL> /* а текст BLOB появляется ниже каждой строки */

SET COUNT включает/выключает отображение количества строк, найденных по запросам.

SQL> SET COUNT [ON | OFF] ;

ON- отображать сообщение «найденные строки» (rows returned).

OFF- не отображать сообщение «найденные строки» (rows returned). Значение по умолчанию.

Пример:

SQL> SET COUNT ON ;

SQL> SELECT * FROM WIZZO WHERE FAVEFOOD = ‘Pizza’ ; SQL> /* отображаются данные */

40 rows returned

SET ECHO включает/выключает отображение команд до их выполнения. Значение по умолчанию ON, но вы можете переключить его в OFF при направлении вашего вывода в файл скрипта.

SQL> SET ECHO [ON | OFF] ; /* значение по умолчанию ON */

ON — включает отображение команд. OFF- отключает отображение команд. Пример скрипта wizzo.sql:

SET ECHO OFF;

= ‘Pizza’ ; = ‘Sardines’ ;

SELECT * FROM WIZZO WHERE FAVEFOOD SET ECHO ON ;

SELECT * FROM WIZZO WHERE FAVEFOOD EXIT;

SQL > INPUT wizzo.sql ; WIZTYPE FAVEFOOD

alpha Pizza

epsilon Pizza

SELECT * FROM WIZZO WHERE FAVEFOOD = ‘Sardines’ ; WIZTYPE FAVEFOOD

gamma Sardines

lamda Sardines

SET NAMES задает набор символов, который будет активным в транзакциях базы данных. Это особенно важно, если в вашей базе данных набором символов по умолчанию является NONE. ЕСЛИ наборы символов клиента и базы данных не соответствуют друг другу, вы рискуете получить ошибки транслитерации и сохранить неверные данные при использовании isql для выполнения изменений, добавлений или поиска данных (включая отыскиваемые изменения и удаления).

Команда SET NAMES доступна в скриптах^[147].

SQL> SET NAMES набор-символов ;

где набор-символов — имя активируемого набора символов. Значение по умолчанию

NONE.

Пример из скрипта:

SET NAMES WIN1251 ;

CONNECT ‘HOTCHICKEN:/usr/firebird/examples/employee.gdb’ ;

SET PLAN задает, нужно ли отображать план запроса оптимизатора.

SQL> SET PLAN [ON|OFF ];

ON — включает отображение плана запроса. Это значение по умолчанию. OFF — отключает отображение плана запроса.

Для сокращения вы можете опускать ON | OFF и просто использовать SET PLAN для переключения режима.

Пример из скрипта:

SET PLAN ON ;

SELECT JOB_COUNTRY, MIN_SALARY FROM JOB

WHERE MIN_SALARY > 50000 AND JOB_COONTRY = ‘Sweden’;

SQL> INPUT iscript.sql

PLAN (JOB INDEX (RDB$FOREIGN3,MINSALX,MAXSALX) JOB COUNTRY MIN SALARY

Sweden 120550.00

SET PLANONLY задает только подготовку запросов SELECT и отображение плана без выполнения самого запроса.

SQL> SET PLANONLY ON | OFF;

Команда работает как переключатель. Аргумент необязателен.

SET SQLDIALECT устанавливает SQL-диалект Firebird в то значение, которое было задано для сессии клиента. Если в сессии открыто соединение с базой данных с диалектом, отличным от того, который задан в команде, будет выдано предупреждение, и программа спросит вас, хотите ли вы подтвердить выполненную работу (если такая была).

SQL> SET SQL DIALECT N ;

где n — номер диалекта, n равен 1 для диалекта 1,2 — для диалекта 2 и 3 — для диалекта 3.

Пример:

SQL> SET SQL DIALECT 3 ;

SET STATS определяет, отображать ли статистику выполнения, которая будет следовать за выходными данными запроса.

SQL> SET STATS [ON|OFF];

ON — включает отображение статистики выполнения.

OFF- включает отображение статистики выполнения. Это значение по умолчанию.

Вы можете опускать ON | OFF и просто использовать SET STATS в качестве переключателя. На рис. 37.6 показан типичный статистический итог, отображаемый после выходных данных запроса.

Рис. 37.6. Пример SET STATS

SET STATISTICS

SET STATISTICS является командой SQL (не isql), которую вы можете использовать в isql — так же, как и в других программах — для вычисления селективности индек- са. Здесь об этом упоминается, потому что, неудивительно, люди часто путают ее с SET STATS. Чтобы узнать, почему селективность является важной для очень динамичных таблиц, см. разд. «Темы оптимизации» в конце главы 18.

Синтаксис этой команды SET STATISTICS имя-индекса. Оператор может быть выполнен только пользователем, который владеет индексом.

SET TERM задает символ, который будет использоваться в качестве терминатора команды или оператора. Он доступен в скриптах. См. замечания об этой команде ранее в данной главе.

SQL> SET TERM строка ;

где строка- символ или символы, которые будут использоваться как терминатор оператора. Значение по умолчанию «;».

Пример:

SET TERM ^^;

CREATE PROCEDURE ADD_WIZTYPE (WIZTYPE VARCHAR (16) , FAVEFOOD VARCHAR ( 20) ) AS

BEGIN

INSERT INTO WIZZO(WIZTYPE, FAVEFOOD) VALUES ( :WIZTYPE, :FAVEFOOD) ; END ^

SET TERM ;^

SET TIME задает, отображать ли время в значении DATE (только диалект 1).

SQL> SET TIME [ON|OFF ];

ON — включает отображение времени в значении DATE диалекта 1.

OFF- отключает отображение времени в значении DATE диалекта 1. Это значение по умолчанию.

Пример:

SQL> SELECT HIRE_DATE FROM EMPLOYEE WHERE EMP_NO = 145; HIRE_DATE

16-MAY-2004

SQL>SET TIME ON ;

SQL> SELECT HIRE_DATE FROM EMPLOYEE WHERE EMP_NO = 145; HIRE DATE

16-MAY-2004 18:20:00

SET WARNINGS задает, выводить ли предупреждающие сообщения. Можно использовать SET WNG как простой переключатель.

SQL> SET WARNINGS [ON |OFF ];

ON- включает отображение предупреждений, если они были отключены, или если сессия была запущена с переключателем -nowamings.

OFF- отключает отображение предупреждений, если они были включены.

Выход из интерактивной сессии isql

Для выхода из утилиты isql и отката (roll back) всей неподтвержденной работы введите:

SQL> QUIT;

Для выхода из утилиты isql и подтверждения всей работы введите:

SQL> EXIT;

Командный режим

Хотя isql имеет некоторые удобные интерактивные возможности, она не ограничена только этим режимом. Многие интерактивные команды доступны также в виде переключателей командной строки. Некоторые функции isql, такие как извлечение метаданных, доступны только из окна командной строки. Операции над входными и выходными файлами не обязательно должны быть интерактивными- фактически вызов isql с переключателями -i[nput] и -o[utput] не вызывает интерактивного режима.

Команды выполняются и после завершения, они автоматически возвращают управление окну командной строки. Вызовы isql также могут находиться внутри скриптов командной строки или внутри пакетных файлов.

Некоторые переключатели могут быть использованы при вызове интерактивного окна isql. Они представлены в табл. 37.1.

Выполнение isql в командном режиме

Откройте окно командной строки и перейдите в каталог Firebird /bin вашей инсталляции сервера или клиента Firebird. Используйте следующий синтаксис для вызовов isql:

isql [режимы] [имя-базы-данных] [-u[ser] <имя-пользователя> -pas[sword] <пароль>]

Для операций SYSDBA вы можете задать переменные операционной системы ISC_USER и ISC_PASSWORD и не вводить их в командах. Для деятельности пользователей, не являющихся SYSDBA, вам всегда нужно задавать учетные данные для операций с базой данных и/или с объектами.

Терминатором по умолчанию является точка с запятой (;). Вы можете заменить ее любым символом или группой символов с помощью режима в командной строке.

! ! !

ПРИМЕЧАНИЕ. Если вы выполняете команду соединения с базой данных для выполнения скрипта, а его набор символов по умолчанию NONE, вам нужно в ваш скрипт включить команду SET NAMES.

. ! .

Вы можете установить диалект isql из командной строки при вызове isql:

isql -s n ;

где n = 1, 2 или 3.

Переключатели командной строки

Требуются только начальные символы переключателей. Вы также можете набрать любую часть текста в квадратных скобках, показанного в табл. 37.1, включая полное название режима. Например, задание -n, -no, -noauto имеет одинаковый эффект.

Таблица 37.1. Переключатели для режимов командной строки isql

Режим	Описание
-a	Извлекает все операторы DDL из указанной базы, а также операторы, не являющиеся операторами DDL
-d[atabase] имя	Используется с переключателем -x (извлечь). Изменяет имя базы данных в операторе CREATE DATABASE, извлеченном в файл. Путь к файлу должен быть полностью определен. Без переключателя -d CREATE DATABASE появляется в виде комментария в стиле языка С с использованием имени базы данных, заданным в командной строке
-с[ache]	Задает количество страниц в кэше, применяемом в этом соединении с базой данных. Вы можете использовать этот переключатель для того, чтобы на время перекрыть размер кэша, установленный на текущий момент для базы данных
-е[cho]	Отображает каждый оператор перед его выполнением (так называемое эхо)
-ex[tract]	Извлекает операторы DDL из указанной базы данных и отображает их на экране, если только вывод не был переназначен в файл
-i[nput] файл	Читает команды не с клавиатурного ввода, а из входного файла. В аргументе файл должен быть указан полный путь. Входные файлы могут содержать команды -input, которые вызывают другие файлы, позволяя выполнить ветвление, а затем вернуться, isql подтверждает работу текущего файла до открытия следующего
-m[erge stderr]	Объединяет вывод stderr с stdout. Полезно для помещения вывода и ошибок в один файл при выполнении isql в скрипте командной строки или из пакетного файла
-n[oauto]	Отключает автоматическое подтверждение операторов DDL. По умолчанию операторы DDL подтверждаются автоматически в раздельных транзакциях
-nowarnings	Отображает предупреждающие сообщения, если и только если появилась ошибка (по умолчанию isql отображает любое сообщение, возвращенное в векторе состояния, даже если не появлялось ошибок)
-o[utput] файл	Записывает результаты в выходной файл, а не в стандартный вывод. Аргумент файл должен содержать полный путь к файлу
-pas[sword] пароль	Используется вместе с -user для задания пароля при соединении с удаленным сервером или когда это требуется для локальной операции. Для доступа пароль и пользователь должны представлять существующую запись в базе данных безопасности на сервере
-page[length] n	В результате запроса выводит заголовки столбцов через каждые n строк, а не через 20 заданных по умолчанию
-q[uiet]	Подавляет вывод сообщения «Use CONNECT or CREATE DATABASE . . .» при отсутствии пути к базе данных в командной строке
-r[ole] имя-роли	Передает имя-роли вместе с учетными данными пользователя при соединении с базой данных
-s[ql dialect] n	Интерпретирует последовательность команд как диалект n до конца сессии или пока диалект не будет изменен оператором SET SQL DIALECT. См. разд. «Установка диалекта в isql» ранее в этой главе
-t[erminator] x	Изменяет символ завершения оператора со значения по умолчанию точка с запятой (;) на x, где x- один символ или любая последовательность символов
-u[ser] пользователь	Используется вместе с -password. Задает имя пользователя при соединении с удаленным сервером. Для доступа пароль и пользователь должны представлять существующую запись в базе данных безопасности на сервере
-x	То же самое, что и -extract
-z	Отображает версию программы isql

Извлечение метаданных

В командной строке вы можете использовать режим -extract для вывода операторов DDL, которые определяют метаданные в базе данных.

Все зарезервированные слова и объекты извлекаются в файл в виде символов в верхнем регистре, если только локальный язык не использует набор символов, который не имеет верхнего регистра. Выходной скрипт создается с подтверждением каждого набора команд, следовательно, на каждую таблицу можно ссылаться в последующих определениях. Выходной файл включает имя объекта и его владельца, если он определен.

Необязательный флаг -output перенаправляет вывод в указанный файл. Используйте следующий синтаксис:

isql [[-extract | -x][-a] [[-output | -о] выходной-файл]] база-данных

Режим -x может быть использован в качестве сокращения для -extract. Флаг -а указывает утилите isql на необходимость извлечения всех объектов базы данных. Обратите внимание, что спецификация выходного файла выходной-файл должна содержать полный путь к файлу и должна следовать после флага -output. Имя файла и путь извлекаемой базы данных могут находиться в конце команды.

Вы можете использовать результирующий текстовый файл для:

* проверки текущего состояния системных таблиц базы данных перед планированием изменений. Это особенно полезно, если база данных значительно изменялась после ее создания;

* создания базы данных со схемой, идентичной схеме извлекаемой базы данных;

* открытия в вашем текстовом редакторе для выполнения изменений определения базы данных или для создания нового исходного файла базы данных.

! ! !

ПРИМЕЧАНИЕ. Функция -extract не всегда бывает столь разумной, как должна бы быть по отношению к зависимостям. Иногда необходимо редактировать выходной файл для изменения порядка создания таблиц.

. ! .

Использование isql -extract

Следующий оператор извлекает схему SQL из базы данных employee.fdb в файл скрипта схемы с именем employee.sql:

isql -extract -output /data/scripts/employee.sql /data/employee.fdb Эта команда эквивалентна:

isql -x -output /data/scripts/employee.sql /data/employee.fdb He извлекаются следующие объекты и элементы:

* системные таблицы и просмотры, системные триггеры;

* коды внешних функций и фильтров BLOB (они не являются частью базы данных);

* атрибуты владельца объектов.

Использование isql -a

Режим -(е)x (tract) извлекает метаданные только для объектов SQL. Если вы хотите извлечь скрипт схемы, который включает такие объявления, как DECLARE EXTERNAL FUNCTION и DECLARE FILTER, используйте режим -а.

Например, для извлечения операторов DDL из базы данных employee.fdb и помещения в файл employee.sql введите:

isql -a -output /data/scripts/employee.sql /data/employee.fdb

Пора дальше

Теперь мы рассмотрим gbak, утилиту командной строки для резервного копирования и чистки базы данных.

ГЛАВА 38. Резервное копирование и восстановление баз данных (gbak).

Корректное резервное копирование базы данных Firebird компактно сохраняет метаданные и данные базы данных в файле на жестком диске или на другом запоминающем устройстве. Настоятельно рекомендуется перезаписывать файлы резервных копий на сменные носители и хранить в физически защищенном месте в стороне от сервера.

Регулярное резервное копирование является основной для поддержания базы данных в хорошем состоянии, обеспечения целостности данных, безопасности и возможности избежать неприятностей. Утилита командной строки резервного копирования и восстановления данных в Firebird gbak создает и восстанавливает резервные копии ваших баз данных. Она создает независимый от платформы архив фиксированного снимка базы данных, который может быть записан в дисковый файл, и он при желании может быть сжат посредством утилит сторонних разработчиков.

Резервная копия Firebird является «горячей» копией — нормальная работа с базой данных может продолжаться в то время, как gbak анализирует метаданные и записывает файл копии. Операция выполняется в транзакции SNAPSHOT, захватывающей состояние базы данных, которое она имела на момент старта транзакции. Изменения данных, которые клиенты подтверждают в базе данных после начала резервного копирования, не записываются в файл копии.

! ! !

ВНИМАНИЕ! Операционные системы обычно включают средства для архивирования файлов баз данных. Не полагайтесь на копии ваших баз данных Firebird, выполненные такими утилитами или утилитами файловой системы, или утилитами сжатия данных, такими как gzip или WinZip, если работа базы данных полностью не завершена. Подобные копии баз данных не являются «гигиеничными» — неубранный мусор будет восстановлен вместе с другими данными файла. Поскольку эти утилиты обычно используют низкоуровневые блокировки диска, их использование приводит к разрушению базы данных, если при их выполнении сохраняются живые соединения с базой данных.

. ! .

Файлы gbak

Утилита gbak анализирует и разбивает на части файлы Firebird, сохраняя отдельно метаданные и данные в компактном формате. Копия, сделанная gbak, не является файлом базы данных и не будет распознаваться сервером. Чтобы стать используемой, она должна быть восстановлена в формат Firebird, который будет читаем сервером с учетом версии gbak, соответствующей версии выполняемого сервера Firebird.

При восстановлении файлов копии в формат базы данных gbak выполняет проверку метаданных и данных перед внутренним использованием языка запросов для воссоздания базы данных и наполнения ее данными.

Если обнаружено разрушение данных, gbak останавливает восстановление и выдает сообщение. Возможность этой утилиты анализировать проблемы делает ее неоценимо полезной при попытках восстановления разрушенной базы данных. Если вы находитесь в такой грустной ситуации, обратитесь к приложению 4.

! ! !

ВНИМАНИЕ! Выполнение резервного копирования является лишь одной стороной защиты схемы. Если вы ослеплены верой в сохранение целостности при резервном копировании, то, независимо от используемой вами системы резервного копирования, вы будете неизбежно наказаны. Тот факт, что копирование завершилось, не является гарантией, что копия будет восстановлена. Делайте тестовое восстановление периодически или регулярно вместе с резервным копированием.

. ! .

Другие таланты gbak

Утилита gbak также выполняет последовательность других важных задач в процессе анализа, сохранения и восстановления базы данных. Одни являются автоматическими, другие должны быть запрошены при использовании переключателей при вызове программы из командной строки.

В процессе копирования gbak выполняет сборку мусора устаревших записей — необязательный переключатель, выполняется по умолчанию. Если он включен, его действие появляется, даже если вы не восстанавливаете копию, а начинаете работать с чистым файлом. Заметьте при этом, что выполнение gbak не упаковывает базу, как это делает копирование — выполняйте полную сборку мусора для выполнения этого.

Задачи восстановления могут включать:

* балансировку индексов для улучшения производительности вашей базы данных;

* освобождение пространства, занимаемого удаленными записями, и упаковку остальных данных. Это часто уменьшает размер базы данных и улучшает производительность с «упакованными» данными;

* по желанию изменение размера страницы при восстановлении;

* изменение владельца базы данных. Это по желанию- но смотрите! Это может привести к авариям, если вы не будете осторожны;

* обновление базы данных InterBase до Firebird или с меньшей версии базы данных Firebird до более высокой версии (например, обновление ODS);

* разделение базы данных на множество файлов или изменение размеров существующих нескольких файлов. Это выполняется по желанию;

* распределение многофайловой базы данных на несколько дисков. Это выполняется по желанию.

Копирование и восстановление также играют важную роль при наличии неприятных событий, которые могут разрушать базы данных. Подробности осуществления стратегии восстановления базы данных см. в приложении 4.

Обновление структуры на диске (ODS)

Вероятно, основным изменением в новых релизах сервера Firebird является изменение структуры на диске (Оп-Disk Structure, ODS). Если ODS изменилась, и вы хотите использовать преимущества новых возможностей Firebird, обновите ваши базы данных до новой ODS. Новая версия сервера может работать с базами данных, созданными в некоторых предыдущих версиях, однако сервер не может использовать свои новые возможности для старой базы данных с более низким значением ODS.

Вы можете использовать большинство баз данных Firebird 1.0.x непосредственно в Firebird 1.5, хотя ODS версии 1.5 (10.1) выше, чем в версии 1.0.x (10.0). Тем не менее рекомендуется выполнить процедуру обновления для ваших баз данных, обновив их с 10.0 до 10.1, для получения преимуществ повышения производительности за счет возможности индексирования системных таблиц в версии 1.5.

Для обновления существующих баз данных до новой версии ODS выполните следующие шаги:

1. Перед инсталляцией новой версии ODS Firebird выполните резервное копирование баз данных с использованием старой версии gbak.

2. Установите новую версию сервера Firebird, как описано в главе 1.

3. После инсталляции новой версии восстановите базы данных с использованием утилиты gbak новой версии из каталога /bin корневого каталога Firebird.

Диалект 1 баз данных

Диалект 1 базы данных остается диалектом 1 и после восстановления базы данных. База данных остается ограниченной возможностями языка InterBase 5, хотя некоторые ограничения применяются к диалекту 1 баз данных в новой версии ODS, которые не применялись к InterBase 5. Например, в Firebird есть множество новых зарезервированных слов, которые будут недопустимыми в базе данных диалекта 1. Полный список зарезервированных слов см. в приложении 11.

Немного отойдя от обсуждаемой темы, скажем, что можно изменить диалект восстановленной базы данных диалекта 1 в диалект 3 при использовании инструмента gfix, обсуждаемого в главе 39. Однако такая миграция не является простым делом. Язык не является единственным, в чем различаются диалекты. Различия в типах данных не менее важны, если не более.

Например, домены и столбцы чисел с фиксированной точкой сохраняют свои старые атрибуты при изменении базы данных до диалекта 3. Типы NUMERIC и DECIMAL С точностью выше 10 в диалекте 1 хранятся в виде DOUBLE PRECISION. Преобразование в

64-битовые числа с фиксированной точкой не выполняется при изменении диалекта на 3 — вы должны создать новые столбцы требуемого типа и выполнить преобразование старых значений в новые столбцы.

Firebird унаследовал некоторые возможности для выполнения миграции из диалекта 1 в родной SQL-диалект Firebird (диалект 3). Известно, что существуют гораздо более простые и безопасные способы выполнить такую миграцию. Лучшие результаты получаются, если создать скрипт, выполнив извлечение метаданных, изменить его при необходимости и восстановить в «пустую» базу данных диалекта 3. Широко доступны прекрасные свободно распространяемые или недорогие инструменты для заполнения вашей новой базы данных вашими старыми данными. См. в приложении 5 рекомендации, а в конце главы 8 ссылки на специальные темы миграции.

Права на выполнение копирования и восстановления базы данных

Использование gbak для копирования и восстановления ограничено пользователем SYSDBA и владельцем этой базы данных.

! ! !

ПРИМЕЧАНИЕ. Любой пользователь может восстановить базу данных при использовании переключателя -c[reate] (см. разд. «Выполнение восстановления»), если создаваемая база данных не будет перекрывать существующую базу данных.

. ! .

Изменение владельца базы данных

Восстановленный файл базы данных или созданный из gbak имеет владельцем того пользователя, который выполнил восстановление. Следовательно, выполнение копирования и восстановления является механизмом для изменения владельца базы данных.

! ! !

ВНИМАНИЕ! Любой может украсть базу данных Firebird путем восстановления базы данных с резервной копии на машине, где ему известен пароль пользователя SYSDBA. Важно обеспечить, чтобы ваши резервные копии были защищены от неавторизованного доступа^[148].

. ! .

Имя пользователя и пароль

Когда Firebird проверяет полномочия при запуске gbak, он определяет пользователя в соответствии со следующей иерархией:

1. Имя пользователя и пароль, заданные переключателями в команде gbak.

2. Только для локального варианта gbak^[149]. Имя пользователя и пароль, заданные в переменных окружения ISC_USERH ISC_PASSWORD, проверяются на присутствие в базе данных безопасности (security.fdb в версии 1.5 и isc4.gdb для версии 1.0.x). Сохранение постоянно установленных значений этих переменных строго не рекомендуется, поскольку крайне небезопасно.

3. Только для POSIX. Если не предоставлено учетных данных пользователя ни на одном из предыдущих уровней, Firebird позволяет пользователю root запускать gbak с сервера или с доверенной машины.

Выполнение копирования

Для вызова gbak или перейдите в каталог Firebird /bin, где размещается gbak, или укажите для утилиты полный путь. Вся команда должна размещаться в одной строке. В описании синтаксиса и примерах логически замкнутые части команды представлены в виде отдельных строк с отступами.

POSIX:

$] ./gbak -b[ackup] <режимы> исходные-данные копил [n]

ИЛИ

$] /opt/firebird/bin/gbak -b[ackup] <режимы> исходные-данные копия [n]

Windows:

C:Program FilesFirebirdFirebird_1_5bin> gbak -b[ackup] <режимы> исходные-данные копия [n]

ИЛИ

С:> C:Program FilesFirebird_1_5bingbak -b[ackup] <режимы> исходные-данные копия [n]

Аргументы для gbak -b[ackup]

исходные-данные- это полный путь и имя файла копируемой базы данных. В Firebird 1.5 это может быть алиас. При копировании многофайловой базы данных используйте имя только первого (первичного) файла базы данных.

копия- полный путь и имя файла, куда помещается резервная копия базы данных.

В случае, когда копия помещается во множество файлов, нужно указать несколько копий. Синтаксический элемент n является целым параметром, включаемым для каждого выходного файла, кроме последнего, для указания размера файла в байтах (по умолчанию). К числу могут быть добавлены буквы в нижнем регистре для задания того, что размер указан в килобайтах (к), мегабайтах (т) или гигабайтах (д). См. следующий пример.

В POSIX копией также может быть STDOUT. В этом случае gbak записывает результат в стандартный вывод (обычно канал)^[150].

Режимы могут быть допустимой комбинацией переключателей из табл. 38.1. Переключатели чувствительны к регистру.

Переключатели копирования

В табл. 38.1 описаны переключатели, которые могут быть использованы в gbak при выполнении копирования.

Таблица 38.1. Переключатели gbak для копирования

Переключатель	Эффект
-b[ackup database]	Утилита gbak выполняет копирование указанной базы данных в файл или на устройства
-со[nvert]	Конвертирует внешние файлы во внутренние таблицы. При восстановлении любая внешняя таблица преобразуется во внутреннюю таблицу базы данных, а связь с внешним файлом будет уничтожена
-е[xpand]	Создает копию без компрессии данных
-fa[ctor] n	Использует коэффициент блокирования n для ленточных устройств
-g[arbage_collect]	Подавляет сборку мусора в процессе копирования. Используйте этот переключатель, если вы планируете сразу же восстановить базу данных с этой копии, gbak не сохраняет мусор, следовательно, не имеет смысла увеличивать накладные расходы, если вы не собираетесь позже использовать старую базу данных
-i[gnore]	Контрольные суммы игнорируются в процессе копирования. Вы можете использовать этот переключатель при повторном запуске копирования, которое аварийно завершилось из-за ошибок контрольных сумм
-1[imbo]	(Буква «L» в нижнем регистре). Зависшие 2РС транзакции будут проигнорированы. Не используйте данный переключатель для регулярного копирования. Это позволяет выполнить чистку после того, как двухфазная транзакция не выполнила подтверждения из-за потери связи с сервером
-m[etadata]	Копируются только метаданные — данные не сохраняются. Это может быть быстрым способом для получения «пустой» базы данных при подготовке к поставке заказчикам продукта
-nt	Создает копию в непереносимом формате. По умолчанию данные, сохраняемые в файлах gbak, записываются в формате XDR, являющемся стандартным протоколом для данных, переносимых между платформами
-ol[d descriptions]	Устаревший переключатель- он сохраняет метаданные в старом формате InterBase
-pa[ssword] пароль	Проверяет пароль перед доступом к базе данных. Это требуется (вместе с именем пользователя) для удаленного копирования, а также для локального, если недоступны переменные окружения ISC_USER и ISC_PASSWORD. Обратите внимание, что сокращение переключателя -password (-pa) для gbak отличается от сокращения для isql (-pas)
-role имя	Соединяется с базой данных под указанной ролью. В настоящий момент похоже, что это бессмысленный переключатель, который вы можете просто проигнорировать
-se[rvice] сервис	Создает файлы копии на хосте, где располагаются и исходные файлы базы данных. Аргумент сервис вызывает Менеджер сервисов на сервере. Подробный синтаксис см. в разд. «Использование gbak с Менеджером сервисов Firebird»
-t[ransportable]	Сохраняет данные gbak в переносимом формате XDR. Это значение по умолчанию. Для сохранения данных в сжатом родном формате используйте переключатель -nt
-u[ser] имя	Проверяет имя пользователя перед доступом к базе данных. Это требуется (вместе с паролем) для удаленного копирования, а также для локального, если недоступны переменные окружения ISC_USER и ISC_PASSWORD
-v[erbose]	Выводит подробные сообщения о том, что делает gbak. Вы можете вывести текст в файл, задав переключатель -y
-y { файл \| suppress output}	Направляет сообщения о состоянии в файл, полный путь к файлу, который вы хотите создать. Операция завершится с ошибкой, если файл уже существует. Если копирование завершится нормально и не был использован переключатель -v[erbose], то этот файл будет пустым, suppress output может быть использовано вместо «молчаливого» копирования, при котором не выводится вообще никаких сообщений
-z	Показывает версии gbak и сервера Firebird

Переносимые копии

Используйте значение по умолчанию, переключатель -transportable, если вы работаете в многоплатформенном окружении. При этом данные записываются в межплатформенном стандартном формате external Data Representation (XDR)^[151], позволяющем программе gbak читать файл на аппаратной платформе, отличной от той, на которой была создана копия.

Копии разных версий

Программа gbak на серверах со значением ODS более низким, чем сервер Firebird, который создал базу данных, обычно не сможет восстановить копию с более высоким значением ODS. Однако на практике версия gbak из InterBase 5.x проявляет способности восстанавливать большинство баз данных диалекта 1, созданных в Firebird 1.0.x.

! ! !

ВНИМАНИЕ! Вы никогда не должны пытаться копировать базы данных программой gbak с версией, не соответствующей версии сервера, с которым выполняется база данных.

. ! .

Копирование в один файл

Для простого локального копирования однофайловой или многофайловой базы данных используйте:

gbak -b d:dataourdata.fdb d:databackupsourdata.fbk

Имя исходного файла задается независимо от того, является ли копируемая база данных однофайловой или многофайловой. Когда вы выполняете копирование многофайловой базы

данных, в команде копирования задавайте только первый файл. Пути ко второму и последующим файлам будут найдены утилитой gbak в базе данных и в заголовках файлов в процессе резервного копирования. Если вы зададите имена последующих файлов, они будут интерпретироваться как имена файлов копии.

Файл копии может иметь любое имя, какое вы ему зададите, если оно будет допустимым в той файловой системе, в которой этот файл записывается.

Копирование многофайловой базы данных во множество файлов

Когда вы копируете многофайловую базу данных во множество файлов с помощью gbak, не требуется соответствия файлов базы данных файлам копии. Если существует более одного файла копии, то имена и размеры файлов копии должны быть заданы для всех файлов за исключением последнего файла в наборе. По умолчанию размер файла (целое число) задается в байтах. Для изменения этого добавьте букву в нижнем регистре, чтобы указать утилите gbak, что задаете размер в килобайтах (к), мегабайтах (m) или гигабайтах (g).

Следующая команда выполняет копирование базы данных в три файла копии в различных разделах файловой системы и выводит подробный протокол. Все это одна команда, множество строк с отступами здесь показаны лишь для удобства чтения.

POSIX:

./gbak -b /data/accounts.fdb /backups/accounts.fbl 2g

/backups2/accounts.fb2 750m /backups3/accounts.fb3

-user SYSDBA -password mlllpOnd

-v -y /logs/backups/accounts.20040703.log

Windows:

gbak -b d:dataaccounts.fdb e:backupsaccounts.fbl 2g

f:backups2accounts.fb2 750m g:backups3accounts.fb3

-user SYSDBA -password mlllpOnd

-v -y d:databackuplogsaccounts.20040703.log

Копия однофайловой базы данных во множество файлов

Если вы копируете однофайловую базу данных во множество файлов копий, синтаксис идентичен. Фактически gbak не интересуется тем, является ли ваша исходная база данных одно- или многофайловой.

Важно отметить некоторые моменты.

* Копирование не будет выполняться, если любой из файлов копии будет меньше чем 2048 байт. Если вы ведете протокол, причина появится в протоколе.

* Утилита gbak заполняет указанные файлы в порядке слева направо. Она не начнет работать со следующим файлом, пока предыдущий не достигнет указанного размера. В предыдущем примере файл accounts.fb3 не будет создан, пока accounts.fb2 не будет заполнен.

* Пути для файлов копии не обязательно должны находиться под физическим управлением хоста, однако если вы используете переключатель -service (см. разд. «Использование gbak с Менеджером сервисов Firebird») в системах, где действуют полномочия к файлам, ваш пользовательский профиль должен иметь соответствующие полномочия на запись данных. В некоторых инсталляциях версии 1.5 это может быть по умолчанию пользователь или группа firebird; в некоторых инсталляциях версии 1.0.x это может быть по умолчанию пользователь interbase.

Копирование только метаданных

Копирование только метаданных обычно требуется для создания «пустой» базы данных, когда вы готовы поставлять систему пользователям, загружать данные или восстанавливать базу с целью миграции. Следующая команда выполняет копирование только метаданных нашей базы данных accounts:

gbak -b -m d:dataaccounts.fdb e:QAaccounts.fbk

Выполнение удаленного копирования

Если вы запускаете gbak с удаленной клиентской машины, она записывает файлы копии в текущий каталог или в локальный каталог, заданный полным путем. Если вы задаете размещение для файла копии, оно должно быть доступно с машины, на которой выполняется gbak. Размещение может быть одним из следующих:

* на диск или в разделе, который размещен на клиентской машине;

* на устройстве, к которому имеет доступ локальная машина (Windows);

* в сетевой файловой системе (NFS) (Linux/UNIX).

При задании переключателя -se[rvice] вы можете вызвать Менеджер сервисов Firebird с удаленного сервера и заставить gbak передать выполнение вашей команды серверу. В этом случае локализация базы данных и файлов копии должна осуществляться с точки зрения размещения с серверной машины. Каталог, из которого была запущена программа gbak, не действует при копировании через Менеджер сервисов. Подробнее о Менеджере сервисов см. далее разд. «Использование gbak с Менеджером сервисов Firebird».

Решение вопросов безопасности

Хорошей мерой предосторожности является присваивание атрибутов только для чтения вашим файлам копии на уровне файловой системы после их создания для предотвращения их случайной или намеренной перезаписи.

Вы можете защитить ваши базы данных от воровства в системах UNIX и Windows NT/2000/XP, поместив файлы копии в каталоги с ограниченным доступом.

! ! !

ВНИМАНИЕ! Файлы копий, которые хранятся в системах Windows 95/98/ME или в областях со свободным доступом в других системах, являются совершенно беззащитными.

. ! .

Возвращаемые коды и ответная реакция

Копирование базы данных, выполняемое под Windows, возвращает код 0 при успешном завершении и 1 при ошибках. Если встретилась ошибка, посмотрите файл firebird.log (interbase.log в версии 1.0.x). Для получения полного протокола копирования используйте переключатели -у и -v.

Выполнение восстановления

Синтаксис восстановления базы данных из копии следующий.

POSIX:

$] ./gbak {-c[reate] | -r[eplace_database] } <режимы> исходная-копия база-данных или

$] /opt/firebird/bin/gbak {-c[reate] | -r[eplace_database] } <режимы> исходная-копия база-данных

Windows:

C:Program FilesFirebirdFirebird_1_5bin> {-c[reate] | -r[eplace database] } <режимы> исходная-копия база-данных

ИЛИ

С: > C:Program FilesFirebird_1_5bingbak {-c[reate] | -r[eplace database] } <режимы> исходная-копия база-данных

Аргументы gbak для восстановления

исходная-копия- полный путь и имя файла копии gbak. Если копия содержит несколько файлов, укажите только первый (первичный) файл gbak. В POSIX исходной- копией может быть также stdin, в этом случае gbak читает свои входные данные из стандартного ввода (обычно канал).

База-данных- полный путь и имя файла восстанавливаемой базы данных. В Firebird 1.5 это может быть алиас. База может быть одним файлом или множеством файлов. Возможные варианты синтаксиса баз данных обсуждаются в следующих разделах этой главы.

Режимы могут быть допустимой комбинацией переключателей из табл. 38.2. Переключатели нечувствительны к регистру.

Переключатели восстановления

В табл. 38.2 перечисляются и описываются переключатели, которые могут быть использованы в gbak при выполнении восстановления базы данных.

Таблица 38.2. Переключатели gbak для выполнения восстановления базы данных

Переключатель	Эффект
-c[reate database]	Восстанавливает базу данных в новый файл
-b[uffers]	Устанавливает значение по умолчанию для размера кэша (в страницах базы данных) для восстанавливаемой базы данных
-i[nactive]	Делает неактивными индексы в восстанавливаемой базе данных. Полезно при повторной попытке восстановления, когда первая попытка оказалась неудачной из-за ошибок индекса
-k[ill]	Подавляет создание ранее определенных теневых копий (shadow)^[152]
-mo[de] {read write \| read_only}	Задает, будет ли восстанавливаемая запись только для чтения или для чтения/записи. Возможные значения read_write (по умолчанию) и read only
-n[o validity]	Удаляет ограничения проверки данных из восстанавливаемых метаданных. Используйте, если вам нужно повторить попытку восстановления, если первая попытка оказалась неудачной из- за нарушений ограничения CHECK
-o[ne at a time]	Восстанавливает одну таблицу за один раз. Может быть использовано при частичном восстановлении, если база данных содержит разрушенные данные
-p[age size] n	Устанавливает новый размер страницы в n байтах (1024, 2048, 4096, 8192 или 16 384). Размер по умолчанию 4096. Размер страницы 16 384 байт невозможен, если файловая система не поддерживает 64-битовый ввод/вывод
-pa[ssword] пароль	Проверяет пароль вместе с -u[ser] перед попыткой создания базы данных
-r[eplace database]	Восстанавливает базу данных, заменяя существующий файл с тем же именем, если он существует; если нет, создает новый файл с указанным именем
-se[rvice] сервис	Создает восстанавливаемую базу данных на хосте, где располагаются файлы копии. Используйте этот переключатель, если вы запустили gbak с удаленного узла и хотите восстановить из копий, размещенных на том же сервере, что и база данных. Это вызывает Менеджер сервисов Firebird на серверной машине, экономит время и сетевой трафик. См. подробности в разд. «Использование gbak с Менеджером сервисов Firebird»
-u[ser] имя	Проверяет пользователя имя вместе с -pa[ssword] перед попыткой создания базы данных
-use_[all space]	Восстанавливает базу данных со 100-процентным заполнением каждой страницы данных вместо значения по умолчанию 80-процентное заполнение. Это идеал для баз данных только для чтения, поскольку им не надо иметь зарезервированное пространство на страницах базы данных для хранения версий строк при добавлении, изменении или удалении. Чтобы вернуть восстановленную базу данных к обычному коэффициенту заполнения, используйте gfix с переключателем -use (т. е. gfix -use reserve)
-v[erbose]	Выводит подробные сведения о том, что выполняет gbak. Вы можете по желанию вывести этот текст в файл при использовании переключателя -у
-y [ файл \| suppress output]	Направляет сообщения в файл, задающий полный путь к файлу, который вы хотите создать. Вызовет ошибку, если указанный файл уже существует. Если восстановление завершится нормально и не был использован переключатель -v[erbose], то этот файл будет пустым. suppress_output может быть использовано вместо «молчаливого» восстановления, при котором не выводится вообще никаких сообщений
-z	Показывает версии gbak и сервера Firebird

Восстанавливать или создавать?

Понятие «восстановление базы данных» при ее перезаписывании родилось в годы, когда дисковое пространство было дороже, чем прием на работу эксперта по реконструкции разрушенной базы данных или формирование группы персонала по данным для восстановления системы компании по бумажным носителям.

Короче говоря, перезаписывание базы данных, чья жизнеспособность вас сильно волнует, не рекомендуется ни при каких условиях. Поразмышляйте о таких тягостных фактах:

* если восстановление завершается с ошибкой, переписываемая база данных навсегда умрет- и дела пойдут плохо при любом восстановлении;

* восстановление поверх существующей базы данных, которая находится в использовании, приведет к ее разрушению;

* возможность пользователей соединяться с частично восстановленной базой данных также приведет к ее разрушению.

! ! !

СОВЕТ. «Горячее» копирование — нормально. «Горячее» восстановление — большая глупость.

. ! .

Если вы все-таки, несмотря на риск, решили использовать -r[epiace_database], то вы можете делать это, если при соединении будете предоставлять учетные данные владельца базы данных или пользователя SYSDBA. Любой пользователь, описанный на сервере, может восстановить базу данных с использованием режима -c[reate]. Рассмотрите последствия этого факта и примите соответствующие меры предосторожности, чтобы уберечь ваши копии от чужих рук.

Объекты, определенные пользователем

При восстановлении копии на сервер, отличный от того, с которого были сделаны копии, вы должны обеспечить существование на новом сервере наборов символов и порядков сортировки, на которые ссылается копия. Копия не может быть восстановлена, если отсутствуют языковые объекты.

Библиотеки внешних функций и фильтров BLOB, на которые ссылаются объявления в базе данных, точно гак же должны присутствовать, чтобы работа происходила без ошибок.

Восстановление в один файл

Следующая команда выполняет простое восстановление из одного файла копии в один файл базы данных:

gbak -с d:databackupsourdata.fbk d:dataourdata_trial.fdb

Многофайловое восстановление

Один или несколько файлов копии могут быть восстановлены в одно- или многотомные файлы базы данных. Не существует требования соответствия один к одному между томами файлов копии и томами файлов базы данных.

При восстановлении из многофайловой копии вы должны указать все файлы копии в том порядке, в котором они создавались, gbak громко пожалуется, если получит список в неправильном порядке или какой-нибудь том будет отсутствовать.

Для файлов базы данных вы должны задать параметр размера для каждого файла за исключением последнего. Минимальное значение- 200 страниц базы данных. Размер последнего файла всегда увеличивается до размера, необходимого для заполнения доступного пространства.

Восстановление однотомной копии в многотомную базу данных

POSIX:

./gbak -с /backups/stocks.fbk /data/stocks_trial.fdb -user SYSDBA -password mlllpOnd

-v -y /logs/backups/stocks_r.20040703.log

Windows:

gbak -c e:backupsstocks.fbk d:datastocks_trial.fdb -user SYSDBA -password mlllpOnd

-v -y d:databackuplogsstocks_r.20040703.log

Если вы зададите несколько файлов базы данных, но имеющих небольшой объем данных, то размер файлов будет достаточно мал — приблизительно 800 Кбайт для первого файла и 4 Кбайт для последующих. В процессе заполнения данными они будут последовательно увеличиваться в размерах до заданной величины.

Восстановление многотомной копии в однотомную базу данных

POSIX:

/gbak -с /backups/accounts.fbl /backups2/accounts.fb2

/backups3/accounts.fb3 /data/accounts_trial.fdb

-user SYSDBA -password mlllp0nd

-v -y /logs/backups/accounts.20040703.log

Windows:

gbak -c e:backupsaccounts.fbl f:backups2accounts.fb2

g:backups3accounts.fb3 d:dataaccounts_trial.fdb

-user SYSDBA -password mlllpOnd

-v -y d:databackuplogsaccounts.20040703.log

Восстановление нескольких файлов из нескольких файлов

POSIX:

/gbak -с /backups/accounts.fbl /backups2/accounts.fb2

/backups3/accounts.fb3 /data/accounts_trial.fdl 500000

/data/accounts_trial.fd2

-user SYSDBA -password mlllpOnd

-v -y /logs/backups/accounts.20040703.log

Windows:

gbak -c e:backupsaccounts.fbl f:backups2accounts.fb2

g:backups3accounts.fb3 d:dataaccounts_trial.fdb 500000

d:dataaccount_trial.fd2

-user SYSDBA -password mlllp0nd

-v -y d:databackuplogsaccounts.20040703.log

Возвращаемые коды и ответная реакция

Восстановление базы данных, выполняемое под Windows, возвращает код 0 при успешном завершении и 1 при ошибках. Если встретилась ошибка, посмотрите файл firebird.log (interbase.log в версии 1.0.x).

Размер страницы и размер кэша по умолчанию

При восстановлении вы можете изменить размер страницы, включив в команду переключатель -р[age_size], за которым следует целое число, задающее размер в байтах. Допустимые размеры страниц см. в табл. 38.2.

В этом примере gbak восстанавливает базу данных с размером страницы 8192 байт:

gbak -с -р 8192 d:databackupsourdata.fbk d:dataourdata_trial.fdb

Аналогичным образом вы можете использовать восстановление для изменения размера кэша базы данных по умолчанию (в страницах или в «буферах»):

gbak -с -buffers 10000 d:databackupsourdata.fbk d:dataourdata_trial.fdb

Размер страницы и производительность

Размер восстанавливаемой базы данных задается в страницах базы данных. Размер файла базы данных по умолчанию равен 200 страницам. Размер страницы базы данных по умолчанию 4 Кбайт, следовательно, если размер страницы не был изменен, то размер базы данных по умолчанию будет 800 Кбайт. Этого достаточно только для очень маленькой базы данных.

Изменение размера страницы может повысить производительность при определенных условиях.

* Firebird работает лучше, если размер строк много меньше размера страницы. Подумайте об увеличении размера страницы, если база данных содержит часто используемые таблицы с большими строками данных.

* Если база данных содержит большие индексы, то больший размер страницы базы данных уменьшает количество уровней в индексном дереве. Чем меньше глубина индекса, тем быстрее он может быть просмотрен. Подумайте об увеличении размера страницы, если глубина индекса превышает три для любого часто используемого индекса. См. главу 18, особенно разд. «Тема оптимизации» ближе к концу главы и замечания по использованию утилиты gstat для определения того, насколько хорошо выполняются ваши индексы.

* Хранение и отыскание данных BLOB наиболее эффективны, когда целый BLOB располагается на одной странице базы данных. Если приложение хранит множество BLOB, превышающих 4 Кбайт, больший размер страницы сокращает время доступа к данным BLOB.

* Сокращение размера страницы может быть более подходящим, если большинство транзакций используют только небольшое количество строк данных, поскольку объем перемещаемых туда и обратно данных будет меньше, и меньше памяти будет использовано для дискового кэша.

Использование gbak с Менеджером сервисов Firebird

Переключатель -se[rvice_mgr] вызывает Менеджер сервисов на (обычно) удаленном сервере. Это может сэкономить значительный объем времени и сетевого трафика, когда вы хотите создавать файлы копии или базы данных на том же хосте, где размещается база данных.

На сервере Windows с локальным соединением использование Менеджера сервисов не дает никаких преимуществ.

На сервере POSIX это экономит время и трафик — даже при локальном соединении.

Если вы выполняете gbak с переключателем -service, то утилита работает другим образом. Это приводит к тому, что gbak вызывает функции копирования и восстановления Менеджера сервисов Firebird на сервере, где находится база данных.

Вы можете копировать во множество файлов и восстанавливать из множества файлов при использовании Менеджера сервисов.

Переключатель -se получает аргумент, который состоит из имени хоста подключенного сервера с константной строкой service_mgr через специальный символ. Синтаксис этого аргумента варьируется в соответствии с используемым сетевым протоколом:

* TCP/IP: hostname: service_mgrj

* именованные каналы (Named Pipes): \hostnameservice_mgr.

Восстановление в POSIX

Пользователь, который был текущим на сервере, когда был вызван Менеджер серверов для выполнения копирования — root, firebird или interbase — является владельцем файла копии на уровне файловой системы, что позволяет читать его только этим пользователем.

Когда вам нужно восстановить базу данных на сервере POSIX, которая была скопирована с использованием Менеджера сервисов, вы должны или использовать Менеджер сервисов, или соединиться с системой как владелец этого файла.

Когда режим -service не используется, владение файлом копии присваивается тому, кто выполнял gbak.

Эти ограничения не применяются к платформе Windows.

Копирование

В этом примере мы копируем базу данных, находящуюся на диске D: удаленного сервера, в файл копии на диске F: той же самой удаленной машины. Мы направляем подробный отчет об операции в файл протокола в другом каталоге. Как обычно, пример является одной строкой:

gbak -b -se hotchicken :service_mgr

d: datastocks.fdb

f:backupsstocks.20040715.fbk

-v -y f:backupslogsstocks.20040715.log

! ! !

ПРИМЕЧАНИЕ. Порядок переключателей имеет значение, когда вы используете переключатель -se. Если вы хотите определить файл протокола, убедитесь, что вы поместили его после задания хост-сервера, чтобы избежать ошибки в команде, по причине невозможности отыскать размещение файла протокола.

. ! .

Восстановление

Следующий пример восстанавливает многотомную базу данных из каталога /january на сервере hotchicken в каталог /currentdb. Он использует переключатель -r[epiace_database] и будет перезаписывать базу данных magic.fdb, если она будет найдена в /currentdb. Первые два файла восстанавливаемой базы данных имеют длину 500 страниц, а последний будет увеличиваться в размерах по необходимости.

gbak -r -user frodo -pas pipeweed -se hotchicken:service_mgr

/january/magicl.fbk /january/magic2.fbk /january/magicLast.fbk

/currentdb/magic.fdb 500 /currentdb/magic.fd2 500

/currentdb/magic.fd3

Следующий пример выполняется на сервере hotchicken и восстанавливает копию, которая находится на hotchicken, на другой сервер с именем icarus:

gbak -с -user frodo -pas pipeweed -se hotchicken:service_mgr

/january/magic. fbk j carus : /currentdb/raagic. fdb

Сообщение об ошибках gbak

В табл. 38.3 описаны сообщения об ошибках, которые могут возникнуть в процессе копирования и восстановления, вместе с некоторыми советами, как поступать с этими ошибками.

Таблица 38.3. Сообщения об ошибках gbak при копировании и восстановлении

Сообщение об ошибке	Причины и рекомендуемые действия
Array dimension for column <string> is invalid (Ошибочная размерность массива для столбца <строка>)	Исправьте определение массива перед копированием
Bad attribute for RDB$CHARACTER SETS (Неверный атрибут для RDB$CHARACTER_SETS)	Используется несовместимый набор символов
Bad attribute for RDB$COLLATIONS (Неверный атрибут для RDB$COLLATIONS)	Исправьте атрибут в указанной системной таблице
Bad attribute for table constraint (Неверный атрибут для ограничения таблицы)	Проверьте ограничения целостности. Если ошибка возникла при восстановлении, рассмотрите возможность использования режима -no_validity для удаления проверки ограничений
Blocking factor parameter missing (Отсутствует параметр коэффициента блокирования)	Задайте числовой аргумент для режима «коэффициент» (например, для ленточного устройства для копии)
Cannot commit files (Невозможно подтвердить файлы)	База данных содержит дефекты или нарушения ограничений целостности метаданных. Попытайтесь восстановить таблицы с использованием режима -one at a time или удалите проверку ограничений, используя режим -no_yalidity
Cannot commit index <string> (Невозможно подтвердить индекс <строка>)	Возможно, данные конфликтуют с определенными индексами. Попытайтесь выполнить восстановление с использованием «неактивного» режима для предотвращения создания индексов
Cannot find column for blob … (Невозможно найти столбец blob)	Используйте -one_at_a_time для отыскания проблемной таблицы
Cannot find table <string> . . . (Невозможно найти таблицу <строка>)	То же
Cannot open backup file <string> (Невозможно открыть файл копии <строка>)	Исправьте имя файла копии и выполните снова
Cannot open status and error output file <string> (Невозможно открыть выходной файл состояния и ошибок <строка>)	Сообщения были направлены в файл с неверным именем или в файл, который уже существует. Проверьте формат задания файла или полномочия к каталогу выходного файла, либо удалите существующий файл, либо выберите другое имя для файла протокола
Commit failed on table <stririg> (Ошибка подтверждения таблицы <строка>)	Разрушение данных или нарушение ограничения целостности в указанной таблице. Проверьте метаданные или восстановите «одну таблицу за раз»
Conflicting switches for backup/restore (Конфликт переключателей для копирования/восстановления)	Режим только для копирования и режим только для восстановления были использованы в одной операции. Исправьте и снова выполните команду
Couxd not open file name <string> (Невозможно открыть файл с именем <строка>)	Исправьте имя файла и снова выполните команду
Could not read from file <string> (Невозможно читать из файла <строка>)	Исправьте имя файла и снова выполните команду
Could not write to file <string> (Невозможно писать в файл <строка>)	Исправьте имя файла и снова выполните команду
Datatype n not understood (Тип данных n неизвестен)	Где-то задан неверный тип данных. Проверьте метаданные и при необходимости повторите команду с использованием -one at a time
Database format n is too old to restore to (Формат базы данных слишком старый для восстановления)	Используемая версия gbak несовместима с версией Firebird, которым создавалась база данных, указанная для копирования. Попытайтесь скопировать эту базу данных с использованием режима -expand или -old, а затем восстановите ее
Database <string> already exists (База данных <строка> уже существует)	Вы использовали -create при восстановлении файла копии, но указанная база данных уже существует. Если вы действительно хотите заменить существующую базу данных, используйте переключатель -R, в противном случае введите другое имя файла базы данных
Could not drop database <string> (database might be in use) (Невозможно удалить базу данных <строка> (возможно, база данных используется))	Вы использовали -replace при восстановлении файла в существующую базу данных, но эта база данных находится в использовании. или измените имя у восстанавливаемой базы данных, или подождите завершения использования существующей базы данных
Do not recognize record type n . . . (He распознан тип записи n)	Проверьте метаданные и при необходимости выполните восстановление с использованием -one at_a time
Do not recognize <string> attribute n — continuing … (He распознан атрибут n <строка> — выполнение продолжается)	Не фатальная ошибка в данных
Do not understand BLOB INFO item n … (Непонятный элемент BLOB INFO)
Error accessing BLOB column <string> — continuing … (Ошибка при обращении к столбцу BLOB <строка> — выполнение продолжается)	Не фатальная ошибка в данных
ERROR: Backup incomplete The backup cannot be written to the target device or file system (ОШИБКА: копирование не завершено. Копия не может быть записана на устройство или в файл системы)	Причинами могут быть недостаточное пространство, проблемы с выводом на устройство или разрушение данных
Error committing metadata for table <string> (Ошибка при подтверждении метаданных для таблицы <строка>)	Возможно, таблица разрушена. При восстановлении базы данных используйте -one at a time для изоляции таблицы
Exiting before completion due to errors (Выход до завершения по причине ошибок)	Это сообщение сопровождает другие сообщения об ошибках и указывает на то, что копирование или восстановление не может быть выполнено. Причину найдите в других сообщениях об ошибках
Expected array dimension n but instead found m (Ожидается размерность массива n, но найдена m)	Проблемы с массивом
Expected array version number n but instead found m (Ожидается номер версии массива n, но найден m)	Проблемы с массивом
Expected backup database <string>, found <string> (Ожидается копия базы данных <строка>, найдена <строка>)	Проверьте имена восстанавливаемых файлов копии
Expected backup description record . . . (Ожидается дескриптор записи копии …)
Expected backup start time <string>, found <string> . . . (Ожидается время начала копирования <строка>, найдено <строка>)
Expected backup version 1, 2, or 3. Found n … (Ожидается версия копии 1, 2 или 3. Найдена n)
Expected blocking factor, encountered <string> (Ожидается коэффициент блокирования, встречено <строка>)	Режим -factor требует числового аргумента
Expected data attribute . . . (Ожидается атрибут данных)
Expected database description record . . . (Ожидается дескриптор записи базы данных)
Expected number of bytes to be skipped, encountered <string> … (Ожидается количество пропускаемых байтов, встречено <строка>)
	Expected page size, encountered <string> (Ожидается размер страницы, встречено <строка>)
Режим -page_size требует числового аргумента	Expected record length . . . (Ожидается длина записи)
	Expected volume number n, found volume m (Ожидается номер тома n, найден том m)
При копировании на множество лент или восстановлении с множества лент убедитесь, что задали правильный номер тома	Expected XDR record length … (Ожидается длина записи XDR)
	Failed in put blr gen id … (Ошибка в put blr gen id …)
	Failed in store blr gen id … (Ошибка в store blr gen id …)
	Failed to create database <string> (Ошибка создания базы данных <строка>)
Указана неверная база данных, возможно, она уже существует	Column <string> used in index <string> seems to have vanished (Столбец <строка>, используемый в индексе <строка>, видимо пропал)
Индекс ссылается на не существующий столбец. Проверьте определение индекса или столбца	Found unknown switch (Найден неизвестный переключатель)
Задан режим, не распознанный утилитой gbak	Index <string> omitted because n of the expected m keys were found .,. (Индекс <строка> пропускается потому, что было найдено n из ожидаемых m ключей)
	Input and output have the same name Disallowed. (Вход и выход имеют одни и те же имена. Отменяется.)
Файлы копии и базы данных должны иметь различные имена. Исправьте имена и выполните заново	Length given for initial file (n) is less than minimum (jn) (Длина, указанная для начального файла (n), меньше минимума (m))
Недостаточное пространство было выделено для восстановления базы данных во множество файлов. Firebird автоматически увеличивает размер страницы до минимального значения. Не требуется никаких действий	Missing parameter for the number of bytes to be skipped … (Отсутствует параметр для количества пропускаемых байтов)

Multiple sources or destinations specified (Задано множество входных или выходных имен)	Только имя одного устройства может быть указано для входа или выхода
No table name for data (He задана таблица для данных)	База данных содержит данные, которые не относятся ни к какой таблице. Используйте gfix для проверки или починки базы данных
Page size is allowed only on restore or create (Размер страницы допустим только для восстановления или создания)	Режим -page size был использован при копировании вместо восстановления
Page size parameter missing (Отсутствует параметр размера страницы)	Режим -page_size требует числового аргумента
Page size specified (n bytes) rounded up to in bytes (Заданный размер страницы (n байтов) округляется до m байтов)	Не фатальная ошибка. Неверный размер страницы округляется до величины 1024, 2048, 4096, 8192 или 16 384 — которая ближе к указанной
Page size specified (n) greater than limit (16 384 bytes) (Указанный размер страницы (n) больше максимального значения (16 384 байт))	Задайте размер страницы 1024, 2048, 4096, 8192 или 16 384
Password parameter missing (Отсутствует параметр пароль)	Копирование или восстановление обращается к удаленному серверу. Используйте переключатель -password и задайте пароль
Protection is not there yet (Запита пока не существует)	Используется нереализованный режим
-unprotected	Redirect location for output is not specified (Перенаправление размещения для вывода не задано)
Вы задали режим, зарезервированный для будущего использования в Firebird	REPLACE specified, but the first file <Jstring> is a database (Задано REPLACE, но первым файлом <строка> является база данных)
Проверьте, чтобы именем файла, следующим за режимом -replace, был файл копии, а не базы данных	Requires both input and output file names (Требуются имена как входного, так и выходного файла)
Задайте входной и выходной файл при копировании и восстановлении	RESTORE: decompression length error (RESTORE: ошибка длины декомпрессии)
Возможна несовместимость версии gbak, используемой для копирования и gbak, используемой для восстановления. Проверьте, был ли режим -expand задан при копировании
Restore failed for record in table <string> (Ошибка при восстановлении для записи из таблицы <строка>)	Возможно разрушение данных в указанной таблице
Skipped n bytes after reading a bad attribute n . . . (Пропущено n байт после чтения неверного атрибута т)	Не фатально
Skipped n bytes looking for next valid attribute, encountered attribute m … (Пропущено n байт при поиске следующего верного атрибута, встречен атрибут m)	Не фатально
Trigger <string> is invalid . . . (Триггер <строка> неверен)
Unexpected end of file on backup file (Непредвиденное завершение копируемого файла)	Восстановление файла копии завершилось с ошибкой; видимо процедура копирования, которая создала этот файл копии, завершилась ненормально. Если возможно, создайте новый файл копии и используйте его для восстановления базы данных
Unexpected I/O error while accessing <string> backup file (Непредвиденная ошибка ввода/вывода при обращении к файлу копии <строка>)	Вероятно, возникла ошибка диска или другого оборудования при выполнении копирования или восстановления
Unknown switch <string> (Неизвестный переключатель <строка>)	Был задан нераспознанный утилитой gbak режим
User name parameter missing (Отсутствует параметр имя пользователя)	Копирование или восстановление обращается к удаленной машине. Задайте имя пользователя переключателем -user
Validation error on column in table <string> (Ошибка проверки столбца в таблице <строка>)	База данных не может быть восстановлена, потому что содержит данные, которые нарушают ограничение целостности. Попытайтесь удалить ограничения из метаданных, указав при восстановлении -no_validity
Warning — record could not be restored (Предупреждение — запись не может быть восстановлена)	Возможно разрушение указанных данных
Wrong length record, expected n encountered m . . . (Неверная длина записи, ожидается n, встретилась m)

Пора дальше

Утилита gbak имеет большое значение для поддержания базы данных в работоспособном состоянии и для устранения некоторых типов разрушения данных. Другим инструментом, который вы можете использовать для выполнения задач администрирования, ведения и восстановления базы данных, является программа gfix, обсуждаемая дальше. Комбинированное использование gfix и gbak для анализа и иногда починки разрушенной базы данных описывается в приложении 4.

ГЛАВА 39. Утилита gfix.

Как пользователь SYSDBA или владелец базы данных, вы можете использовать административный инструмент командной строки gfix для подключения к базе данных и выполнения разнообразных задач по поддержанию работоспособности и восстановлению базы данных.

Используя gfix, вы можете:

* выполнять чистку (sweep);

* изменять интервал автоматического sweep;

* инициировать закрытие базы данных для получения исключительного доступа и опять переводить базу данных в активное состояние;

* переключаться между синхронным и асинхронным выводом;

* переводить базу данных для чтения/записи в базу данных только для чтения и наоборот;

* изменять диалект;

* устанавливать размер кэша базы данных;

* отыскивать и подтверждать или отменять зависшие транзакции;

* чинить разрушенные базы данных и данные при некоторых условиях;

* активировать и удалять теневые копии базы данных.

Использование gfix

Утилита gfix может быть запущена только из командной строки. Для использования этой утилиты вы должны быть владельцем базы данных или пользователем SYSDBA. Для запуска gfix откройте окно командной строки и перейдите в каталог /bin в корневом каталоге Firebird.

Синтаксис команды gfix:

gfix [режимы] база-данных

База-данных должна быть полным именем первичного файла базы данных, с которой вы собираетесь работать.

Первичный файл однофайловой базы данных является собственно файлом базы данных. Для многофайловых баз данных первичный файл является первым файлом в наборе.

Режимы являются допустимой комбинацией переключателей и, в некоторых случаях, аргументов. Они представлены позже в табл. 39.1. Для большинства переключателей могут быть использованы сокращения. Необязательные символы показаны в квадратных скобках ([ ]).

! ! !

СОВЕТ. Как и в других инструментах командной строки Firebird, вы можете включить любое количество необязательных символов в имя переключателя вплоть до полного имени переключателя, если ни один символ не будет пропущен в последовательности слева направо.

. ! .

Получение доступа к базе данных из gfix

Если вы соединяетесь с сервером удаленно, то в список переключателей вы должны включить имя пользователя и пароль для пользователя SYSDBA или для владельца базы данных. Такими переключателями являются:

-pas[sword] <пароль> -u[ser] <имя>

Следующий пример команды gfix устанавливает синхронный режим (Forced Writes).

POSIX:

bin]$ ./gfix -w sync customer.fdb -pas heureuse -user SYSDBA

Windows:

bin> gfix -w sync customer.fdb -pas heureuse -user SYSDBA

Пользователь и пароль при локальном соединении

Перед стартом сервера для расширенной локальной работы с копией проблемной базы данных или для восстановления транзакции вы можете добавить две системные переменные ISC_USER и ISC PASSWORD для исключения необходимости набора имени и пароля пользователя SYSDBA или владельца базы данных в каждой команде:

shell prompt> SET ISC_USER=SYSDBA

shell prompt> SET ISC_PASSWORD=heureuse

Из соображений безопасности вы должны удалить эти переменные окружения, как только завершите вашу работу. Не рекомендуется конфигурировать эти переменные за пределами видимости вашего текущего окна командной строки или делать их постоянными в системе.

Чистка базы данных

Многоверсионная архитектура Firebird порождает ситуацию, когда множество версий строк данных хранится непосредственно на страницах базы данных. Firebird сохраняет старые версии при изменении или удалении строки. При нормальном ходе событий устаревшие версии записей, созданные изменениями данных, вычищаются фоно- вой сборкой мусора. Однако при некоторых условиях эти старые версии могут оставаться «застрявшими» и накапливаться, приводя к росту файла (файлов) базы данных пропорционально размеру данных, к которым происходит обращение. Иногда застрявшие транзакции могут сильно влиять на производительность.

Чистка базы данных является способом систематического удаления устаревших строк из базы данных и предотвращает ее слишком интенсивный рост. По умолчанию базы данных Firebird всегда установлены в режим автоматически выполняемой чистки при возникновении некоторых условий. Однако, поскольку процесс чистки может влиять на производительность, чистка может быть настроена для оптимизации ее преимуществ при минимизации воздействия на пользователей.

Неплохая стратегия — отключение автоматической чистки и управление чисткой вручную. Вы можете отслеживать статистику базы данных и выполнять ручную чистку или «по потребности», или по составленному графику. Например, можно включить команду очистки в скрипт стоп или в выполняемый по расписанию пакетный файл.

Информацию о том, как статистический отчет по базе данных может помочь в анализе требований к чистке вашей базы данных, см. в разд. «Получение статистики по индексам» главы 18.

Сборка мусора

Firebird выполняет сборку мусора в фоновом режиме для ограничения роста базы данных из-за устаревших версий записей. Сборка мусора освобождает память, отведенную устаревшим версиям строк, насколько это возможно, после освобождения строк транзакциями, их использующими. Транзакции начинают сборку мусора, когда они встречают старые версии строк, отмененные другими транзакциями. Удаленные строки и версии, оставленные после отката транзакции, избегают такой сборки мусора. Строки, к которым редко происходит обращение, также накапливают старые версии.

Еще сборка мусора происходит при резервном копировании базы данных с использованием утилиты gbak, поскольку задача gbak имеет дело с каждой строкой в каждой таблице. Однако gbak не выполняет полной чистки. Как и обычная сборка мусора, она оставляет версии удаленных и отмененных по rollback записей. Чистка является единственным способом избавиться от этого, она выполняется быстрее, чем восстановление базы данных из резервной копии.

Интервал чистки

Интервалом чистки (sweep interval) является установленное для базы данных целое число, которое определяет предел для некоторого набора условий, что приведет к выполнению автоматической чистки.

Сервер Firebird ведет список транзакций. Любая транзакция, находящаяся в любом состоянии, кроме подтвержденного, называется заинтересованной транзакцией. Самая старая из этих «заинтересованных» транзакций (старейшая заинтересованная транзакция, Oldest Interesting Transaction, OIT) отмечает начальную точку для условия, называемого «зазором».

Противоположным концом этого зазора является старейшая транзакция, которая все еще активна: самая старая активная транзакция (Oldest Active Transaction, OAT). Зазор, следовательно, является разностью между OIT и OAT^[153]. Когда величина зазора достигает числа, указанного как интервал чистки, то автоматически запускается чистка во время запуска новой транзакции.

Базы данных создаются с интервалом чистки 20 000.

Существует маленькое, но важное различие: автоматическая чистка не появляется каждые 20 000 транзакций. Она появляется, когда разница между OIT и OAT — зазор — достигает заданного предела. Если приложения базы данных аккуратно подтверждают каждую транзакцию, OAT будет увеличиваться, пока не достигнет предела интервала чистки, и тогда будет запущена чистка.

Изменение интервала чистки

Изменение интервала чистки мало влияет на размер базы данных, если только база данных не накопила очень большого количества отмененных транзакций. Однако если вы замечаете увеличение времени запуска транзакции с момента последней чистки, то уменьшение интервала чистки может помочь сократить накопление объектов, вызванных откатом транзакций.

Если интервал чистки слишком мал, производительность приложения может иметь тенденцию к ухудшению, по причине слишком частого выполнения чистки. В этом случае увеличение интервала чистки может помочь улучшить общую производительность.

Переключателем режима для установки интервала чистки является -h[ousekeeping] n, где n представляет новое значение счетчика (интервала).

gfix -h 10000 /data/accounts.fdb -user SYSDBA-pas masterkey

устанавливает новое значение интервала чистки для accounts.fdb в 10 000.

Отмена автоматической чистки

Вы можете решить отменить автоматическую чистку, если вам нужно исключить случайные, непредсказуемые задержки, возникающие из-за автоматической чистки. Такая отмена не рекомендуется, если только управление старыми версиями записей эффективно не осуществляется альтернативными средствами, такими как отслеживание статистики и регулярное выполнение ручной чистки.

Автоматическая чистка может быть отменена установкой интервала чистки в 0:

./gfix -h 0 /data/accounts.fdb -user SYSDBA-pas masterkey или (Windows):

gfix -h 0 d:dataaccounts.fdb -user SYSDBA-pas masterkey

Выполнение ручной чистки

Ручная чистка может быть выполнена в любое время для освобождения пространства, занимаемого старыми версиями, особенно версиями записей, оставшихся от отмены транзакций и после удалений. Общим правилом является выполнение чистки во время низкой активности сервера базы данных, что исключает конкуренцию с клиентами за ресурсы.

Вы можете выполнять вашу собственную чистку, если:

* вы отслеживаете зазор и собираетесь выбрать подходящее время для устранения «застрявших» старых версий;

* вы считаете, что редкие изменения нечасто посещаемых записей создали запасы несобранного мусора;

* выполнялось большое количество удалений, и вы хотите быстро убрать мусор. Для немедленного запуска чистки:

gfix -sweep С:dataaccounts.fdb -user SYSDBA-pas masterkey

или (POSIX):

./gfix -sweep /data/accounts.fdb -user SYSDBA-pas masterkey

Исключительный доступ для ручной чистки

Чистка базы данных не требует, чтобы база данных была обязательно закрыта — она может

выполняться в любое время — однако она может ухудшить производительность системы и не должна проводиться во время большой загрузки сервера.

Существуют преимущества выполнения чистки с исключительным доступом и когда вся работа клиентов подтверждена. При этих условиях не только больше доступной памяти для операции чистки, но чистка также способна выполнить полное очищение записей данных и состояния транзакций. Зависшие при явных или неявных обрывах соединений транзакции под конец будут переведены в устаревшие, а используемые ими ресурсы будут освобождены.

Далее мы рассмотрим использование gfix для закрытия базы данных и получения к ней исключительного доступа.

Закрытие базы данных

Закрытие базы данных (shutdown) не является тем же самым, что и завершение работы сервера. Сервер продолжает работать и когда база данных закрыта.

База данных неявно находится «в закрытом состоянии», когда не существует активных соединений. Явное закрытие может быть выполнено при использовании gfix с переключателем -sh[ut], чтобы пользователь SYSDBA или владелец базы данных получили к ней исключительный доступ. Когда такое явное закрытие базы данных было выполнено, база данных остается закрытой, пока явно не будет выполнено gfix -о [niine]. Эти две операции называются «закрытие базы данных» и «перевод базы данных в оперативное состояние».

Закрытие базы данных перед остановом сервера

Когда вам понадобится остановить сервер, находящийся в промышленной эксплуатации, возможно вам потребуется применить gfix -shut для закрытия используемых баз данных на этом сервере.

Команда gfix -shut

Синтаксис команды gfix -shut следующий: POSIX:

./gfix -sh[ut] {-at n |-t n |-f n } база-данных Windows:

gfix -sh[ut] {-at n |-t n |-f n } база-данных

Определение аргументов

Переключатель gfix -shut поступает с гремя квалификаторами, которые уточняют стратегию закрытия: -at[tach] n, -tr[an] n и -f[orce] n. В любом случае n устанавливает период ожидания в секундах. Вы должны использовать один аргумент.

-at[tach] n употребляется для предотвращения новых соединений с базой данных. Он не отключает существующие соединения, но блокирует любые новые соединения. Если не будет никаких соединений по прошествии времени ожидания n секунд, то база данных будет переведена в закрытое состояние. Если же еще остаются соединения, то закрытие будет отменено.

-tr[an] n используется для предотвращения запуска новых транзакций. Это не закрывает существующих транзакций, но не позволяет запускать новые. Если не будет никаких соединений по прошествии времени ожидания n секунд, то база данных будет переведена в закрытое состояние. Если еще остаются соединения, то закрытие будет отменено.

-f[orce] n форсированно переведет базу данных в закрытое состояние по прошествии n секунд, независимо от существования соединений или активных транзакций. Это радикальная операция, которая может привести к тому, что пользователи потеряют свою проделанную работу. Она должна быть использована с осторожностью.

! ! !

СОВЕТ. Если вам нужно прибегнуть к переключателю -f[orce], чтобы убить дефектный запрос, то, по крайней мере, будьте вежливы с вашими «хорошо себя ведущими» пользователями и сначала используйте -at[tach] или -tr[an], чтобы дать им возможность сохранить работу и элегантно выйти из своих приложений.

. ! .

Примеры:

gfix -sh -at 300

инициирует закрытие базы данных, что произойдет через 5 минут, если все пользователи отключатся от базы данных.

gfix -sh -f 600

отключит всех пользователей от системы через 10 минут. Любые еще выполняющиеся транзакции будут отменены, а пользователи потеряют проделанную и неподтвержденную работу.

Исключительный доступ

Когда база данных находится в закрытом состоянии, пользователь SYSDBA или ее владелец могут соединиться с ней и получить исключительный доступ. Однако остерегайтесь следующих моментов:

* если владелец или SYSDBA были соединены с базой данных в момент ее закрытия, то сервер не будет блокировать другие подключения к базе данных, даже когда выполнено закрытие;

* когда владелец или SYSDBA соединяется с базой данных после ее закрытия, то другому будет заблокирован к ней доступ — это хорошо. Если тот же пользователь захочет снова к ней подключиться, ему это будет разрешено, что уже не столь хорошо^[154].

Это накладывает ответственность на SYSDBA или на владельца, кому нужен исключительный доступ гарантировать, что ни они, ни кто-либо другой не будет соединен с базой данных с использованием визуального административного инструмента, монитора SQL, другого инструмента командной строки или даже другого режима gfix, например. Когда вы получили исключительный доступ, сохраните его исключительным — не запускайте более одного приложения^[155].

Завершение закрытия

Используйте gfix -o[nline] для отмены закрытия и перевода базы данных в оперативное состояние для доступа множества пользователей. Вы также можете применять это для отмены закрытия по расписанию.

Останов и запуск сервера

Имейте в виду, что останов или запуск сервера не оказывает никакого воздействия на состояние закрытия любой базы данных. Если база данных закрыта, когда сервер остановлен, она будет оставаться в закрытом состоянии и при последующем запуске сервера. Останов сервера не переведет никакую базу данных в закрытое состояние.

! ! !

ПРИМЕЧАНИЕ. Если вы скопировали файл базы данных, которая находится в закрытом состоянии, а затем пытаетесь соединиться с копией, то копия будет в закрытом состоянии.

. ! .

Изменение установок базы данных

Множество режимов команды gfix позволяет установить или изменить различные установки базы данных. Для выполнения таких команд требуются полномочия SYSDBA или владельца базы данных, а также исключительный доступ.

Установка размера кэша по умолчанию

Использование gfix является предпочтительным способом установки размера кэша по умолчанию для базы данных. Важно помнить некоторые моменты.

* Если вы увеличиваете размер страницы, размер кэша соответственно увеличится. Вы должны гарантировать, что вы получите количество физической памяти машины в соответствии с измененным размером кэша. Когда кэш достигнет размера, который слишком велик для хранения в RAM, он начнет записываться на диск, что полностью уберет все преимущества использования кэша.

* В Классическом сервере каждый клиент получает свой собственный кэш. Даже размер кэша по умолчанию в 75 страниц будет слишком большим, если база данных использует большой размер страницы.

Синтаксис:

gfix -b[uffers] n база-данных

Здесь n- размер резервируемого кэша (количество буферов с размером, равным размеру страницы).

Пример:

gfix -b 5000 d:dataaccounts.fdb

Если размер страницы базы данных 8192, то кэш в 5000 страниц займет примерно 40 Мбайт.

Другие режимы кэша

В настоящий момент переключатель -с[ache] n не используется; он зарезервирован для дальнейших реализаций.

Изменение режима доступа

Используйте вариант gfix -mo[de] для переключения режима доступа любого соединения с базой данных между «только для чтения» и «для чтения/записи». В базу только для чтения нельзя совсем выполнить запись — даже пользователю SYSDBA, ее владельцу или любому серверному процессу.

Синтаксис:

gfix -mo[de] {read_write | read_only} база-данных

Для переключения базы данных из режима чтения/записи в режим только для чтения:

./gfix -mo read_only /data/accounts.fdb

Для переключения базы данных из режима только для чтения в режим чтения/записи:

./gfix -mo read_write /data/accounts.fdb

Изменение диалекта базы данных

С переключателем -s[qi_diaiect] вы можете изменить диалект! базы данных на родной для Firebird диалект 3. После этого база данных перестает использовать диалект 1 и начинает подчиняться полным синтаксическим правилам SQL Firebird и может использовать все типы данных Firebird.

Но база данных продолжает хранить все существующие данные и определения в соответствии с диалектом 1. Здесь существует несколько ловушек, в особенности в отношении числовых типов с фиксированной точкой.

Короче говоря, изменение диалекта с помощью gfix не будет ни тактикой быстрой миграции, ни надежным способом миграции из диалекта 1 в диалект 3. Быстрое изменение средствами gfix означает медленный способ полной миграции. Опытные пользователи предлагают вместо этого извлечь скрипт схемы вашей базы данных диалекта 1, изменить подходящим образом определения, а затем использовать инструмент перекачки данных для перемещения старых данных в новую базу.

Если же вы все-таки хотите использовать этот способ, вот синтаксис:

gfix -s[ql_dialectj n база-данных

Здесь n равно 1 или 3.

Например, для изменения диалекта базы данных на 3 выполните:

./gfix -s 3 /data/accounts.fdb

Под Windows вы можете выполнить следующее:

gfix -sql_dialect 3 d:dataaccounts.fdb

Включение и отключение «использовать все пространство»

Firebird заполняет страницы базы данных таким образом, что объем хранимых на странице данных не превышает 80 процентов. Некоторое уплотнение можно получить, изменив коэффициент заполнения на 100 процентов. Это может привести к улучшению производительности при очень большом объеме добавления данных, в особенности если размер строки много меньше размера страницы и множество строк может экономно храниться на одной странице.

Также имеет смысл полностью заполнять страницы в базе данных, если вы планируете распространять ее как базу данных только для чтения, например, в качестве каталога или демонстрационного примера.

Командным переключателем является -u[se], который имеет два аргумента:

gfix -u[se] {reserve | full}

reserve устанавливает использование страницы на 80 процентов, a full устанавливает использование страницы на 100 процентов.

Для включения «использовать все пространство» применяйте команду: ./gfix -use full /demos/catalog.fdb

Для отключения «использовать все пространство» и возврата к 80-процентному заполнению применяйте команду:

./gfix -use reserve /demos/catalog.fdb

! ! !

ПРИМЕЧАНИЕ. Чтобы эта команда работала, база данных должна находиться в режиме чтения/записи.

. ! .

Включение и отключение синхронного вывода

Синонимом синхронного вывода является Forced Writes. Когда поведение является синхронным («Forced Writes включено»), новые записи, новые версии записей и удаления немедленно записываются на диск после пересылки. При асинхронном выводе («Forced Writes отключено») новые и измененные данные сохраняются в кэше файловой системы, полагаясь на поведение операционной системы, когда она выведет их на диск.

Термин «отключение Forced Writes» означает переключение поведения по выводу данных с синхронного на асинхронное.

Синтаксис этой команды:

gfix -w[rite] {sync ! async} Для включения Forced Writes введите: gfix -w sync d:dataaccounts.fdb Для отключения Forced Writes введите:

gfix -w async d:dataaccounts.fdb

Firebird инсталлируется в Windows NT/2000/XP и Linux с включенным режимом Forced Writes. В очень надежной среде с надежной поддержкой бесперебойного питания (UPS) администратор базы данных может отключить Forced Writes для сокращения операций ввода/вывода и улучшения производительности. Когда отключается Forced Writes в менее надежных средах, база данных становится чувствительной к потере данных и даже к их разрушению в случае неуправляемого отключения.

Forced Writes неприменимо в Windows 95. В серверах Windows 98 и ME вы никогда не должны отключать Forced Writes.

Отключение Forced Writes в серверах Windows

Операционные системы Windows менее надежны, чем другие системы в отношении записи на диск кэша. Это проявляется в том, что приложения не могут явно запросить систему Windows записать кэш на диск, система может отложить все выводы на диск до того момента, как файл базы данных будет закрыт.

* Firebird 1.0.x: если Forced Writes не задается для сервера Windows, работающего 24/7 (24 часа, 7 дней в неделю), то запись на диск может никогда не произойти.

* Firebird 1.5: были добавлены новые установки конфигурации для записи буферов кэша на диск в Windows. См. параметры MaxUnfiushedwrites и MaxUnflushedWriteTime (firebird.COnf) В главе 36.

Системное восстановление в Windows ME и XP

Windows ME вместе с XP Ноте и Professional Edition имеет возможность, называемую системным восстановлением, которая вызывает копирование самой файловой системы в файлы с некоторыми суффиксами каждый раз, как происходят операции ввода/вывода. Системное восстановление не является заменой Forced Writes^[156].

Конвертированные базы данных InterBase

Вам следует знать, что база данных Firebird, которая начала свою жизнь в InterBase 6.x (коммерческом или с открытыми текстами), создана с отключенным режимом Forced Writes по умолчанию.

Запрос версии сервера Firebird

Переключатель -z (без параметров) показывает версию gfix и сервера Firebird, инсталлированного на сервере.

Вот синтаксис:

gfix -z

Проверка и починка данных

В повседневных операциях в базе данных иногда происходят события, создающие некоторые проблемы для структуры базы данных.

* Ненормальное завершение сервера. Ненормальное завершение не влияет на целостность базы данных. Однако если Firebird уже назначил страницу данных для неподтвержденных изменений, запрошенных клиентом, эта страница становится бесхозной, «осиротевшей». Поскольку такие страницы являются вполне безобидными, они лишь занимают дисковое пространство, которое должно быть возвращено в свободное пространство. Проверка может отыскать и освободить это пространство.

* Ошибки записи операционной системы или оборудования. Ошибки записи обычно создают проблемы для целостности базы данных. Они могут привести к разрушению или потере структур данных, таких как страницы базы данных и индексы. В худшем случае такие разрушения структур данных могут сделать подтвержденные данные нечитаемыми. Иногда проверка может помочь найти такие разрушенные фрагменты и удалить их.

Когда проверять базу данных

Вы должны проверять базу данных:

* всякий раз при неуспешном копировании базы данных;

* всякий раз, когда приложение получает сообщение об ошибке «разрушена база данных»;

* периодически в качестве регулярной процедуры для отслеживания разрушения структур данных или нераспределенного пространства;

* каждый раз, когда вы подозреваете, что данные разрушены.

Утилита командной строки gbak может быть использована вместе с gfix для выполнения последовательной проверки и починки данных.

Выполнение проверки базы данных

Пров базы данных требует исключительного доступа к базе данных. Без исключительного доступа вы получите сообщение об ошибке:

OBJECT имя-базы-данных IS IN OSE

Для проверки базы данных просто введите команду:

gfix -v

Проверка будет молча отыскивать и освобождать неназначенные страницы или нераспределенные структуры, которые она найдет. Она будет сообщать о любых разрушенных структурах, но не будет пытаться их исправлять. Для получения протокола об ошибках gfix, но без попыток освобождения пространства введите переключатель -n[o_update]:

gfix -v -n

Вы можете заставить проверку игнорировать ошибки контрольных сумм, добавив переключатель -i [gnore]:

gfix -v -i

! ! !

ПРИМЕЧАНИЕ. Даже если вы сможете восстановить исправленную базу данных, которая сообщала об ошибках контрольных сумм, объем потерянных данных трудно будет определить. Если это вас беспокоит, вы можете восстановить вашу базу данных с более ранней копии.

. ! .

Восстановление разрушенной базы данных

Если вы подозреваете, что ваша база данных разрушена, важно точно придерживаться последовательности шагов восстановления, чтобы избежать дальнейших разрушений. Подробное описание рекомендуемой процедуры восстановления см. в приложении 4^[157].

Восстановление транзакций

Утилита gfix предоставляет инструменты для восстановления зависших транзакций 2РС — транзакций с несколькими базами данных после потери соединения с одной из них.

Двухфазное подтверждение

Транзакция, которая используется в нескольких базах данных Firebird, подтверждается в два этапа, или в две фазы. Такое двухфазное подтверждение гарантирует, что если транзакция не может завершить изменения во всех используемых базах данных, она не будет изменять ни одну из них.

На первой фазе двухфазного подтверждения Firebird подготавливает субтранзакцию для каждой базы данных, вовлеченной в операции транзакции, и записывает соответствующие изменения в каждую базу данных.

На второй фазе, следуя точно в том же порядке, что и при их подготовке и записи, Firebird отмечает каждую подтранзакцию как подтвержденную.

Зависшие транзакции

Зависшие (limbo) транзакции- это подтранзакции, которые остались неразрешенными, если возникли какие-то проблемы в соединениях с одной или более базами данных в процессе выполнения второй фазы двухфазного подтверждения, например, ошибки сети или отключение питания. Сервер не может сказать, должны ли зависшие транзакции подтверждаться или следует выполнить их откат.

Следовательно, некоторые записи в базе данных могут оказаться недоступными, пока явно не будут выполнены те действия по разрешению зависших транзакций, с которыми они связаны.

Восстановление транзакции

При использовании gfix, вы имеете множество режимов для получения информации и для разрешения зависших транзакций после ошибок двухфазного подтверждения. Процесс идентификации зависших транзакций и их подтверждение либо откат называется восстановлением транзакций.

Вы можете попытаться восстановить сразу все зависшие транзакции или вы можете выполнять восстановление транзакции за транзакцией, используя идентификатор каждой индивидуальной транзакции.

Поиск зависших транзакций

Для получения списка всех зависших транзакций с индикацией, что произойдет с каждой, если было запрошено автоматическое двухфазное восстановление, используйте переключатель -l[ist]:

gfix -l база-данных

Подсказка для восстановления

Используйте переключатель -p[rompt] вместе с -l[ist] для получения от gfix списка зависших транзакций одну за другой и выдачи вам запроса на выполняемое действие:

COMMIT или ROLLBACK:

gfix -l -р база-данных

Автоматическое двухфазное восстановление

Поскольку зависшие транзакции являются результатом либо ошибок при подтверждении, либо ошибок при откате, сервер знает, как должна каждая из них заканчиваться. Следовательно, автоматическое восстановление просто является способом подтверждения, что вы хотите, чтобы утилита gfix продолжала осуществлять первоначальное намерение, каким оно было, когда двухфазное подтверждение было прервано.

Переключатель-t[wo_phase] {ID | all} инициирует автоматическое двухфазное восстановление.

Используйте all для выполнения двухфазного восстановления всех зависших транзакций:

gfix -t all база-данных

Используйте ID для ввода идентификатора одной транзакции, для которой вы хотите выполнить двухфазное восстановление:

gfix -t nnnnnn база-данных

Здесь nnnnnn — идентификатор транзакции.

Задание подтверждения или отката

Чтобы попытаться разрешить зависшие транзакции их подтверждением, используйте переключатель-c[ommit] {ID | all}. Для восстановления всех зависших транзакций таким способом введите:

gfix -с all база-данных

Для разрешения одной зависшей транзакции попыткой ее подтверждения введите:

gfix -с nnnnnn база-данных

Здесь nnnnnn — идентификатор транзакции.

Для попытки разрешения зависших транзакций путем их отката используйте переключатель -r[ollback] {ID | all}. Для восстановления всех зависших транзакций таким способом введите:

gfix -r all база-данных

Для разрешения одной зависшей транзакции попыткой ее отката введите:

gfix -r nnnnnn база-данных

Здесь nnnnnn — идентификатор транзакции.

Теневые копии

Концепция, создание и поддержка теневых копий базы данных подробно обсуждались в главе 15. Утилита gfix имеет средства для работы с теневыми копиями.

Активизация теневой копии

Ключ для активизации теневой копии, когда база данных «умерла», -ac[tivate]. Синтаксис:

gfix -ас <путь-к-первому-тому-оперативном-копии>

Предположим, что первым томом теневой копии является employee.shl. Находится в каталоге /opt/dbshadows. Вы можете активизировать ее следующей командой:

./gfix -ас /opt/dbshadows/employee.shl

Удаление недоступных теневых копий

Переключатель для удаления недоступных теневых копий -k[ill]. Синтаксис:

gfix -k[ill] база-данных

Для удаления недоступных теневых копий для базы данных employee.fdb введите:

./gfix -k /opt/firebird/examples/employee.fdb

Список переключателей gfix

Все доступные переключатели gfix описаны в табл. 39.1. Часто для одной задачи применимо несколько переключателей. Порядок переключателей не является важным, однако просмотрите предыдущие замечания в этой главе для определения подходящих комбинаций. Комбинации, не имеющие логического смысла, приведут к исключениям.

Таблица 39.1. Список переключателей gfix

Переключатель	Задача	Назначение
-ас[tivate]	файл-оперативной-копии	Оперативная копия
Используется с путем к первичному файлу оперативной копии для активизации оперативного копирования	-at[tach]	Закрытие базы данных
Используется с -shut для предотвращения новых подключений к базе данных за период времени ожидания в n секунд. Закрытие будет отменено, если все еще будут оставаться активные соединения по прошествии n секунд	-b[uffers] n	Буферы кэша
Устанавливает размер буферов кэша базы данных по умолчанию в n страниц. Это рекомендованный способ установки размера кэша базы данных по умолчанию	-ca[che] n	Не используется
	-c[ommit] {ID \| all}	Восстановление транзакций
Подтверждает зависшую транзакцию с идентификатором ID или подтверждает все зависшие транзакции	-f[orce] n	Закрытие базы данных
Используется вместе с -shut для форсированного закрытия базы данных через n секунд — радикальное решение, которое должно быть использовано как последнее средство	-full	Починка данных
Используется вместе с -v[alidate] для проверки структур записей и страниц; освобождает неназначенные фрагменты записей	-h[ousekeeping]	Чистка
Изменяет порог автоматической чистки в n транзакций. Значение по умолчанию 20 000. Устанавливайте n в 0 для отключения автоматической чистки	-i[gnore]	Починка данных
Игнорировать ошибки контрольных сумм при проверке или чистке	-k[ill] база-данных	Теневая копия
Используется вместе с путем к файлу базы данных для уничтожения всех неиспользуемых теневых копий	-l[ist]	Восстановление транзакций
Отображает идентификаторы всех зависших транзакций и указывает, что должно произойти, если будет задано -t [wo_phase] при автоматическом двухфазном подтверждении	-m[end]	Починка данных
Отмечает разрушенные записи как неиспользуемые, следовательно, они будут пропущены при последующей проверке или копировании	-n[o update]	Починка данных
Используется вместе с -v[alidate] для проверки разрушенных или неразмещенных структур, сообщая о них, но не исправляя их	-o[nline]	Закрытие базы данных
Отменяет операцию -shut, которая была в списке, или отменяет выполняющееся в настоящий момент закрытие базы данных	-pa[ssword] пароль	Удаленный доступ
Передает пароль для доступа к базе данных. Для большинства операций gfix это должен быть пароль пользователя SYSDBA, владельца базы данных или (для POSIX) пользователя с привилегиями root	-p[rompt]	Восстановление транзакций
Используется вместе с -l[ist] для перехода в режим подсказок во время восстановления транзакций	-r[ollback] {ID \| all}	Восстановление транзакций
Выполняет откат зависшей транзакции с идентификатором ID или выполняет откат всех зависших транзакций	-s[weep]	Чистка
Запускает немедленную чистку базы данных	-sh[ut]	Закрытие базы данных
Закрывает базу данных. Требует указания	-at[ach], -f[orce], или -tr[an] n	-sql[dialect] n
Миграция	n = 3. Изменяет SQL диалект базы данных с 1 на 3. Не изменяет данные и не преобразует существующие типы данных	-t[wo_phase] {ID \| all}
Восстановление транзакций	Выполняет автоматическое двухфазное восстановление либо транзакции с указанным идентификатором ID, либо всех зависших транзакций	Назначение
-tr[an] n	Закрытие базы данных	Используется вместе с -shut для запрета запуска новых транзакций в процессе ожидания n секунд. Закрытие будет отменено, если все еще будут активные транзакции по прошествии n секунд
-use {reserve \| full}	Использование всего пространства	Включает или отключает использование полного пространства, отведенного для страниц базы данных. Режим по умолчанию reserve использует 80-процентное заполнение. При переключении на full будет использоваться все выделенное пространство
-user пользователь	Удаленный доступ	Передает имя пользователя для доступа к базе данных. Для большинства операций gfix это должен быть пользователь SYSDBA, владелец базы данных или (для POSIX) пользователь с привилегиями root
-v[alidate]	Починка данных	Определяет и освобождает страницы, которые были выделены, ко не назначены никакой структуре данных. Также сообщает о разрушенных структурах
-w[rite] {sync \| async}	Forced Writes	Включает или отключает Forced Writes (синхронную буферизованную запись), sync включает, async отключает
-z	Информация	Выводит версию gfix и сервера Firebird

Сообщения об ошибках gfix

В табл. 39.2 представлены исключения, которые могут появиться в командах gfix вместе с советами, как скорректировать ваши команды.

Таблица 39.2. Сообщения об ошибках gfix

Сообщение об ошибке	Причины и рекомендуемые действия
Database file name <string> already given (Имя файла базы данных <строка> уже указано)	Режим командной строки был интерпретирован как файл базы данных, потому что режим не начинался со знака минус (-) или наклонной черты (/). Исправьте синтаксис
Invalid switch (Неверный переключатель)	Режим командной строки не был распознан
Incompatible switch combinations (Несовместимая комбинация переключателей)	Вы задали, по меньшей мере, два режима, которые не работают вместе, либо вы указали режим, который не имеет смысла без другого режима (например, -full)
More limbo transactions than fit. Try again. (Зависших транзакций больше допустимого. Попытайтесь снова.)	База данных содержит больше зависших транзакций, чем gfix может вывести в одной сессии. Подтвердите или отмените некоторые из зависших транзакций, а затем снова выполните операцию
Numeric value required (Требуется числовое значение)	Режим -housekeeping требует одного неотрицательного аргумента, задающего количество транзакций для чистки
Please retry, specifying <string> (Пожалуйста, повторите, задав <строка>)	Должно быть задано имя файла и по меньшей мере один режим
Transaction number or «all» required (Требуется номер транзакции или «all»)	Вы указали -commit, -rollback или -two_phase без задания требуемого аргумента
-mode read only or read write -mode read only или read write	Режим -mode принимает в качестве переключателя read only или read write
«read_only» or «read_write» required (Требуется «read only» или «read write»)	Режим -mode должен сопровождаться одним из этих аргументов

Пора дальше

В конце этой книги глава 40 представляет техническое описание наименее дружественной для пользователя утилиты Lock Print, а также подсистему блокировки ресурсов. Она включает объяснения связанных с блокировками установок в firebird.conf или isc config/ibconfig, которые иначе могли бы остаться для большинства из нас большой загадкой!

ГЛАВА 40. Менеджер блокировок.

Блокировки используются в многопользовательских средах для синхронизации работы и предотвращения разрушения целостности процессов работой других процессов. Firebird использует как средства блокировки операционной системы, так и собственный менеджер блокировок для координации доступа к базе данных.

Эта тема сложна для читателя, который является новичком в Firebird. Она погружает его в некоторые серьезные технические области, с которыми знакомят гуру^[158] с блестящими глазами на конференциях. Пока утилиты Lock Print — довольно сырые сейчас- являются серьезным инструментом для сложных задач поиска ошибок при подходах, которые некоторые разработчики применяют в их интерфейсах приложений. В любом случае примите эту главу как возможный запасной вариант, который может спасти вас в один «прекрасный» день.

Вы можете спросить, почему мы должны интересоваться системой блокировки, которая ничего не блокирует? Параллельность и согласованность, видимые клиентам, основываются на транзакциях и управляются через версии записей. Однако ответ в том, что Firebird использует блокировки внутренне. Он поддерживает согласованность структуры на диске через блокировки и осторожную запись. В то же время он также использует сервисы блокировок операционной системы для управления доступом к файлам базы данных для предотвращения открытия Суперсервером дважды одного и того же файла под разными именами.

Блокировка, основанная на транзакциях, позволяет осуществлять блокировки в любой точке выполнения транзакции. Однако, однажды установленные, они могут быть сняты только в конце. Даже явная блокировка на уровне оператора, введенная в Firebird 1.5, не имеет «разблокирующего» оператора. Операторы выполняются в обычной транзакции; подтверждение или откат транзакции снимает блокировку как обычно.

Firebird остерегается двухфазной блокировки для своего первичного управления параллельностью, поскольку она не может обеспечить адекватных уровней параллельности и соответствия, Firebird использует блокировки в процессе изменений для предотвращения записи двумя транзакциями на одну и ту же страницу в одно и то же время. Внутренняя блокировка управляется самой системой. Объекты в системе — называемые «владельцами блокировки» или просто «владельцами» — состязаются в блокировке множества ресурсов. Не удивительно, что эти ресурсы включают в себя и страницы, содержащие записи, отмеченные для обновления.

Когда транзакция получает блокировку страницы, она сохраняет эту блокировку, пока Менеджер блокировок не попросит ее освободить страницу; следовательно, транзакция может выполнить множество изменений на одной странице без ее освобождения и повторного чтения.

Менеджер блокировок Firebird

В Суперсервере о Менеджере блокировок можно думать как об отдельном «управляющем центре», с которым договариваются транзакции о приобретении прав на выполнение запросов. Менеджер блокировок включает в себя фрагмент памяти и некоторые подпрограммы для обработки запросов. Его память разделена на различные блоки: блоки блокировок, которые ссылаются на ресурсы; другие блоки, которые представляют транзакции и другие объекты, запрашивающие блокировки, и блоки истории. Его подпрограммы ответственны за получение и управление запросами владельцев на блокировки ресурсов, выделение блоков и их освобождение. Суперсервер также управляет «защелками» для координации изменений в параллельных транзакциях.

Классический сервер проще: владельцы запрашивают получение контроля над таблицей блокировок, так что каждый код процесса управления блокировкой может запрашивать, предоставлять и освобождать блокировки для их владельцев.

Состояния блока

Каждая операционная система предоставляет некий вид механизма использования/освобождения для синхронизации событий ресурсов. Поскольку для Firebird нужен управляющий механизм с множеством состояний, он реализует свою собственную систему управления блокировками с семью состояниями. На рис. 40.1 показано решение уровней блокировок.

* 0 — свободно (no lock).

* 1 — пустая блокировка (null lock), что соответствует интересу объекта, не накладывающего ограничений в использовании другими. Запрос пустой блокировки позволяет транзакции читать заблокированные данные.

* 2 — разделяемое чтение (shared read), что позволяет записывать. Разделяемое чтение является обычным режимом для блокировки таблицы, когда транзакция изменяет некоторые части таблицы.

* 3 — защищенное чтение (protected read), что позволяет другим читать, но не писать. Защищенное чтение является обычным режимом для блокировки страницы базы данных, которая находится в кэше и не была изменена.

Рис. 40.1. Состояния внутренних блокировок Firebird

* 4 — совместно используемая запись (shared write), другой обычный режим блокировки таблицы. Совместно используемая запись совместима с разделяемым чтением и другими совместно используемыми записями, но не с любым защищенным режимом.

* 5 — защищенная запись (protected write), которая допускает разделяемое чтение и пустую блокировку и ничего больше. Защищенная запись используется при режиме CONSISTENCY и для такой блокировки базы данных, что обычные пользователи не могут получить к ней доступ.

* 6 — исключительный доступ (exclusive), используется для внутренних структур, когда параллельный доступ может повлиять на изменения или привести к тому, что вторая транзакция будет читать незавершенные изменения данных.

Таблица блокировок

Менеджер блокировок управляет таблицей блокировок для координации совместного использования ресурсов в клиентских потоках. Информация, предоставляемая здесь, может быть полезной при попытках исправить ситуации взаимных блокировок, например;

* все в настоящий момент заблокировано в системе в своем состоянии;

* глобальная статистика заголовков, такая как размер таблицы блокировок, множество свободных блокировок, множество взаимных блокировок и т.д.;

* флаги процессов, указывающие, была ли передана блокировка или она осуществляет ожидание.

Блокировки сохраняются в последовательностях, каждая последовательность идентифицируется номером в соответствии с типом блокируемого ресурса. Номера последовательностей объясняются в табл. 40.5.

Использование пустой блокировки

Запущенная транзакция использует таблицу блокировок в качестве доски объявлений. Чтобы исключить сборку мусора версий записей, которые нужны другой транзакции, каждая транзакция должна знать самое старое действие, которое видит другая транзакция. Вот как это сделано:

1. При старте транзакция сохраняет в области данных собственного блока идентификатор старейшей транзакции, которая еще выполняется (активна).

2. Затем она устанавливает пустую блокировку на все параллельные транзакции. Когда будет получен каждый блок, ей возвращается содержимое области данных.

Новая транзакция проверяет блок каждой существующей транзакции для отыскания идентификатора старейшей транзакции, о которой знает каждая активная транзакция.

Свободные списки

Списки владельцев, ресурсов и запросов представлены в виде цепочки с возможностью проходить по ним вперед и назад. В начале каждого блока находится указатель на следующий блок. Списки указателей используются Менеджером блокировок, когда ему нужно разместить новый блок и постараться найти свободные блоки для повторного использования. Он выделит новый блок, только если не существует свободных блоков нужного типа и размера.

Свободные элементы содержат прямые и обратные указатели на первый и последний свободный блок соответственно.

Взаимные блокировки

Взаимная блокировка (deadlock) возникает, когда владелец А хочет блокировать ресурс 1, который заблокирован владельцем В, а владелец В хочет заблокировать ресурс 2, который заблокирован процессом А. Она также может появиться для одного ресурса, если два владельца начинают с блокировки чтения и запрашивают блокировки на запись.

Эту ситуацию владельцы не могут разрешить без постороннего вмешательства. Решение осуществляется, когда взаимная блокировка определяется последующим сканированием и Менеджер блокировок возвращает ошибку одному владельцу или другому. Интервал сканирования блокировок по умолчанию — параметр DeadiockTimeout в файле конфигурации- составляет 10 секунд. Этот интервал не используется при условиях, где присутствует WAIT. Ожидание является нормальным в системе, которая управляет параллельными изменениями, и не требует затрат на сканирование.

«Взаимные блокировки», которые не являются взаимными блокировками

Сообщения о взаимных блокировках могут не помочь точно указать на «проблемы deadlock», наблюдаемые в ваших приложениях. Взаимные блокировки всегда включают двух владельцев (или две раздельные транзакции), каждый из которых мешает другому. Firebird имеет привычку выдавать клиентам сообщения «взаимные блокировки» при большинстве конфликтов блокировок, хотя истинная взаимная блокировка — как было описано ранее — довольно редкое явление.

* Ошибки, возвращаемые как «конфликт блокировки» при запросах блокировки NO WAIT, не фиксируются в таблице блокировок как взаимные блокировки, потому что ожидает только один владелец.

* Ошибки, возвращаемые как «взаимные блокировки» с последующим сообщением «Update conflicts with concurrent update» (Конфликты обновлений при параллельном обновлении), также не являются настоящими взаимными блокировками. В этом случае произошло всего лишь то, что один владелец изменил (или удалил) строку и «пошел» дальше. Другой параллельный владелец попытался изменить (или удалить) ту же самую запись, ждал освобождения ее первым владельцем, а теперь получил ошибку, потому что последняя подтвержденная версия записи была изменена.

Таблица блокировок данных может быть выведена в более или менее читаемом формате с помощью утилиты Lock Print.

Утилита Lock Print

Программой, которая выбирает статистику таблицы блокировки, является исполняемый модуль fb_lock_print, который можно найти в каталоге /bin каталога инсталляции Firebird. (Для версии 1.0.x ищите iblockpr.exe в Windows или gds_lock_pr в POSIX.) Доступны два синтаксиса: один для статичного отчета, другой для задания интерактивной выборки в указанных интервалах.

Синтаксис для Firebird 1.5 и выше:

fb_lock jprint <переключатели>

Версия 1.0.x, POSIX:

gds_lock_pr <переключатели>

Версия 1.0.x, Windows:

iblockpr <переключател14>

Программа fb lock print имеет множество переключателей, описанных в табл. 40.1. Когда не задано ни одного переключателя, fb lock print выводит итоговую информацию, описывающую заголовок блока и владельцев, связанных с Менеджером блокировок.

Таблица 40.1. Переключатели для отчетов Lock Print

Переключатель	Описание
(нет переключателей)	Выводит итоговую информацию, описывающую заголовок блока и владельцев, связанных с Менеджером блокировок
-a	Выводит содержимое таблицы блокировок, включая заголовок блока, группы блоков, группы владельцев и группы запросов. Группа блока представляет ресурс, который должен быть заблокирован (база данных, транзакция, отношение, страница базы данных и т.д.), и идентифицирует владельца, который имеет или запросил блокирование этого объекта. Группа запроса описывает запрос в процессе блокирования ресурса. Группа запроса может описывать или предоставленную блокировку, или ожидание завершения запроса на блокировку
-с	Указывает, что таблица блокировок должна быть скопирована, а не использована сама. Копирование является быстрым и создает мгновенный статичный снимок таблицы блокировок. Тем не менее он остановит все процессы доступа к базе данных на время своего выполнения
-f	Задает, что анализ должен быть выполнен на указанном файле, а не на настоящем файле блокировки. К сожалению, этот переключатель не работает в Firebird
-h	Выводит только историю
-i <переключатели> <t> <n>	Запускает интерактивный режим (см. разд. «Интерактивные отчеты»). Если указано только -i, то выводятся все данные
-l	Выводит только группы блоков
-n	Указывает, что не существует «никакого моста». Мост является переходным механизмом, распознающим множество серверов различных версий Firebird на одной машине. Это не доступно в версиях Firebird 1.0.x или 1.5, но, скорее всего, будет реализовано в следующих версиях Firebird
-o	Выводит группы владельцев
-p	То же, что и -о. (Группы владельцев, используемых в вызовах групп процессов.)
-r	Выводит группы запросов
-s <n>	Выводит заголовок таблицы блокировок, группы владельцев и блокировки указанных серий. Аргумент <n> указывает тип блокируемого ресурса, который вы хотите отобразить. Номера см. в табл. 40.5
-t	Выводит статистику для всех серий (только интерактивный отчет)
-w	Выводит «граф ожидания» — блоки владельцев с запросами ожидания, чего они ожидают, чего ожидают их владельцы и т.д. В этом отчете вы можете просмотреть, какой запрос владельца блокирует другие запросы в таблице блокировок. Это самый простой способ найти блокировки, хотя полное отображение блокировок даст вам много больше информации относительно взаимосвязей, находящихся в очереди запросов

Статичные отчеты

Статичные отчеты выводят текущее состояние (мгновенный снимок) таблицы блокировок. Допустимы любые переключатели, за исключением -i, вы можете «затолкать» в него множество переключателей. Например, для вывода «ожидающего» графа плюс группы истории введите:

fb_lock_print -wh

Интерактивные отчеты

Вторая форма собирает заданные номера выборок фиксированных интервалов и создает интерактивный отчет, отслеживающий текущую деятельность таблицы блокировок. Синтаксис:

fb_lock_print [-i{a,o,w}] [t n]

t задает время в секундах между выборками, n задает количество требуемых выборок. Если вы не задаете значений для n и r, то значением по умолчанию является n= 1.

Выборки осуществляются n раз через интервалы в t секунд. Одна группа выводится для каждой выборки. Средние значения выборки выводятся в конце каждого столбца.

Следующий оператор выводит статистику (доступ к таблице блокировок) в виде 10 выборок, осуществляемых каждые 3 секунды:

fb_lock_print -ia 3 10

В конце этой главы представлен

мгновенный снимок интерактивного отчета с объяснением значения каждого столбца.

! ! !

СОВЕТ. Ограничения буфера в окне командной строки могут привести к «исчезновению» выходных данных за исключением последней части. Вы можете направить вывод утилите more (или less в POSIX).

fb_lock_print -wh | more

Когда окно будет заполнено, нажмите или держите нажатой клавишу <Return> (Enter) для отображения дальнейшего вывода по строке за раз. Нажатие клавиш <Ctrl>+<C> завершает more или less.

. ! .

Вывод отчета в файл

Обычно результаты являются достаточно большими, чтобы их просматривать с консоли. Вы можете направить их в выходной файл, например, в каталог с именем /data/server_reports/ (ваш выбор!) таким образом:

fb_lock_print -а > /data/server_reports/lock.txt

Если вы видите, что Lock Print выполняется более минуты или двух или замечаете, что он заполняет ваш диск, остановите его с помощью <Ctrl>+<C> или эквивалента вашей платформы.

Группы отображаются в порядке внутренних списков. Новые группы помещаются в начало списка, следовательно, обновленная таблица блокировок будет показана в строках в обратном порядке. Поскольку группы блоков, запросов и владельцев освобождаются и используются заново, порядок становится полным беспорядком. Текстовый редактор будет весьма полезным для исследования отношений.

Простое использование Lock Print

Мы посмотрим на пример очень простой статистики, полученной от Lock Print без переключателей.

* Заголовок блока всегда будет первым.

* Далее идут группы владельцев — за группой владельца следуют все запросы этого владельца. Каждый владелец цепочки выводится с его запросами.

* После всех владельцев и запросов идут блокировки.

* Последним элементом является история записей.

Группа Lock_Header

Вначале мы рассмотрим только группу заголовка блока, которая описывает основную конфигурацию и состояние таблицы блокировок. На рис. 40.2 числа добавлены для ссылок на каждый элемент при объяснении в табл. 40.2.

Рис. 40.2. Группа Lock_Header

Наш отчет Lock Print представляет только что созданную базу данных, к которой имеет доступ одна копия isql в версии l.O.x Суперсервера для Windows.

Таблица 40.2. Записи группы Lock_Header

№	Элемент	Объяснение
1	LOCK_HEADER_BLOCK	Первая группа любого отчета Lock Print. Каждый отчет выводит ровно одну группу заголовка блока
2	Version (Версия)	Номер версии Менеджера блокировок. В Firebird 1.5 версия будет 115 для Суперсервера и 5 для Классического сервера. В Firebird 1.0.x (для нашего примера) такими версиями будут 114 и 4 соответственно
3	Active owner (Активный владелец)	Смещение в группе владельца, представляющее владельца, который в настоящий момент управляет таблицей блокировок, если такой существует. Если ни один процесс не пишет в таблицу блокировок, то активным владельцем будет 0
4	Length (Длина)	Общий объем памяти, выделенный таблице блокировок в байтах
5	Used (Используется)	Наибольшая величина смещения в таблице блокировок, которая используется в настоящий момент. В таблице могут существовать свободные группы между ее началом и используемой точкой, если владельцы приходят и уходят. Перед созданием новых групп между этой точкой и концом таблицы блокировок могут быть заново использованы свободные блоки
6	Semmask (Маска семафора)	В системах, которые используют статичные семафоры (например, POSIX), это указатель на блок SMB, содержащий количество используемых семафоров. Когда нужен семафор, и ни один недоступен, Менеджер блокировок проходит через группы владельцев для поиска того владельца, имеющего неиспользуемый семафор. Если такого нет, система выдает сообщение об ошибке «Semaphores are exhausted» (Семафоры исчерпаны), означающее, что все скомпилированные в системе семафоры используются
7	Flags (Флаги)	Определены два битовых флага: LHB_shut_manager, который, если установлен, указывает, что база данных остановлена, и Менеджер блокировок не может обработать больше запросов; и LHB_lock ordering. В Firebird значение по умолчанию LHB_lock_ordering означает, что блокировки предоставляются в порядке запросов (порядок FIFO — первый пришел — первый ушел). Другая установка связана с устаревшей стратегией блокировки и сейчас не используется
8	Enqs (Запросы в очереди)	Запросы в очереди- полученные запросы на блокировку. Это число включает запросы, которые пока не могут быть удовлетворены, и запросы, которые могут быть удовлетворены немедленно, но не запросы, которые пришли и ушли
9	Converts (Преобразования)	Запросы на повышение уровня блокировки. Процесс, поддерживающий блокировку ресурса, запросит изменение режима, если изменяется его доступ к этому ресурсу. Преобразование происходит от блокировки низшего уровня (например, совместное чтение) к более ограничивающему уровню (например, исключительный доступ). Например, транзакция в режиме CONCURRENCY, которая читала данные таблицы, и решает изменить данные в этой таблице, будет преобразовывать свою блокировку от разделяемого чтения до разделяемой записи. Преобразования являются наиболее частыми для блокировок страниц, поскольку страница обычно вначале читается, а потом изменяется
10	Rejects (Отмены)	Запросы, которые не могут быть удовлетворены. Это могут быть блокировки, запрошенные в режиме «no wait», или это могут быть блокировки, которые были отменены, потому что приводили к взаимным блокировкам. Так как методы доступа иногда запрашивают блокировку «по wait» для внутренних структур, то вы увидите отмены, даже если все транзакции выполняются в режиме «wait» и не существует конфликтов между их операциями
11	Blocks(Блоки)	Запросы, которые не могут быть удовлетворены немедленно, потому что некоторый другой владелец имеет несовместимую блокировку на этот ресурс
12	Deadlock scans (Сканирование взаимных блокировок)	Сколько раз Менеджер блокировок просматривает цепочку блокировок и владельцев в процессе поиска взаимных блокировок. Менеджер блокировок начинает сканирование, когда процесс ожидает блокировки в течение 10 секунд
13	Deadlocks (Взаимные блокировки)	Количество найденных взаимных блокировок. См. разд. «Взаимные блокировки»
14	Scan interval (Интервал сканирования)	Количество секунд, которые ожидает Менеджер блокировок после начала запроса, прежде чем запустить сканирование взаимных блокировок. Значение по умолчанию 10 секунд
15	acquires(Запросы)	Количество раз, сколько владелец- или сервер от имени конкретного владельца — запрашивает исключительное управление для таблицы блокировок, чтобы выполнить изменения
16	Acquire blocks (Заблокированные запросы)	Количество раз, сколько владелец — или сервер от имени конкретного владельца — находился в состоянии ожидания при запросе исключительного управления таблицей блокировок
17	Spin count (Количество блокировок)	Это режим для ожидания взаимной блокировки и повторения запроса к таблице блокировок Firebird. По умолчанию установлено в ноль (отключено), но может быть сделано доступным в файле конфигурации
18	Mutex wait (Ожидание блокировок)	Процент попыток, которые были заблокированы, когда владелец старался обратиться к таблице блокировок — т.е. ((acquire blocks) / (acquires)) * 100
19	Hash slots (Сегменты хэша)	Ресурсы размещены в хэш-таблице. Они хранятся согласно значению. По умолчанию хэш-таблица содержит 101 сегмент. Это значение (которое должно быть простым числом) может быть увеличено в файле конфигурации. Оно никогда не должно быть меньше, чем 101
20	Hash lengths(Длина сегмента)	При каждом сегменте находятся ресурсы (заблокированные группы). Этот элемент сообщает минимальную, среднюю и максимальную длину цепочки заблокированных групп, находящихся в сегменте. Среднее значение, большее чем 15, означает, что не достаточно сегментов
21	Remove node (Удаление узла)	Для устранения проблем, которые являются следствием того, что активный владелец зависает при запросе к таблице блокировок с потенциально осуществленными ее изменениями, владелец сообщает о намерении удалить узел из этой таблицы. После успешного завершения операции владелец удаляет сообщение об удалении. Если любой другой владелец находит сообщение об удалении, которое он не создавал, он наводит порядок
22	Insert queue (Добавить очередь)	Эквивалент предыдущей схеме удаления узла, за исключением того, что здесь узел добавляется
23	Insert prior (Предыдущее добавление)	Для очистки ошибочного добавления необходимо знать не только, что было добавлено, но и где это размещалось. Это как раз где
24	Owners (Владельцы)	Количество владельцев, которые соединены с таблицей блокировок. Только один из этих владельцев может изменять таблицу в конкретный момент («активный владелец»). Другие владельцы ожидают освобождения блокировок. В нашем примере существует четыре владельца, не являющихся активными. Два владельца подключены через isql; один может быть подключен через DSQL, а еще один — сама база данных
25	Free owners (Свободные владельцы)	Количество блоков владельцев, выделенных владельцам, которые завершили их соединения, оставив блоки неиспользованными. В этом случае, вероятно, существует две транзакции, занимавшиеся созданием базы данных, которые были подтверждены
26	Free locks (Свободные блокировки)	Группы блокировок определяют ресурс (база данных, отношение, транзакция и т.д.), который заблокирован, а не блок на ресурс. Этот элемент является количеством групп блокировок, которые были освобождены, но пока повторно не использованы. В этом случае существует один свободный блок. Когда владелец запрашивает блокировку на ресурс, который в настоящий момент не заблокирован, Менеджер блокировок сначала просматривает список свободных блоков в заголовке блока. Если существует группа с нужным размером ключа, то эта группа блока будет использована. Если нет, то в свободной памяти будет размещена новая группа блока
27	Free requests (Свободные запросы)	Группы запросов идентифицируют запросы на блокировки ресурсов, неважно, удовлетворенные или нет. Этот элемент является количеством групп запросов, которые были освобождены и не использованы повторно
28	Lock ordering (Порядок блокировок)	Порядок блокировок означает получение запросов на блокировку в порядке их поступления, даже если последующие запросы должны быть обслужены немедленно. Включено, если флаг LHB_lock_ordering (см. элемент 7) установлен, и является значением по умолчанию для Firebird, т. к. обеспечивает оптимальную производительность. Альтернативой является (не используется сейчас) предоставление блокировок всем владельцам, желающим совместно использовать и «подавлять» владельцев, которые имеют существующие запросы. Эта не используемая стратегия гарантирует, что участники будут обработаны быстро, однако с риском причинения вреда другим

Группы владельцев

Группы владельцев, изображенные на рис. 40.3, описывают транзакцию или другого пользователя в Менеджере блокировок. Владельцы делятся на несколько типов, идентифицируемых пятью числами:

* 1 — процесс;

* 2 — база данных;

* 3 — клиентское соединение (в Классическом сервере клиентские соединения всегда являются процессами);

* 4 — транзакция;

* 5 — фиктивный процесс.

! ! !

ПРИМЕЧАНИЕ. В некоторых причудливых соглашениях по кодированию на транзакции никогда не ссылаются по их идентификационному номеру (4), а используют номер 255.

. ! .

Рис. 40.3. Группа владельца

Смещение конкретной группы владельца в таблице блокировок (здесь это 11 872) также является идентификатором, используемым в заголовке блокировок для «активного владельца», если этот пользователь активно изменяет таблицу блокировки. Первая выводимая группа обычно является номером, выводимым в группу заголовка блокировок в начале списка владельцев. Значение в списке указателей является полем в группе, которое содержит прямые и обратные указатели на группы владельцев. В табл. 40.3 описаны записи в группе владельца.

! ! !

СОВЕТ. Если вы просматриваете ваш результат работы утилиты в текстовом редакторе, вы можете отыскивать запросы, принадлежащие идентификатору этого владельца.

. ! .

Таблица 40.3. Записи групп владельцев

№	Элемент	Объяснение
1	OWNER BLOCK	Идентифицирует конкретного владельца. Число, следующее за заголовком (11 872), является смещением группы владельца в таблице блокировок и используется в качестве идентификатора владельца в этой таблице
2	Owner ID (Идентификатор владельца)	В Классическом сервере владельцем всегда является процесс, а идентификатором владельца всегда является идентификатор процесса. В Суперсервере владельцем является либо база данных и идентификатором будет группа базы данных, либо соединение и идентификатором будет эта группа соединения
3	Owner type (Тип владельца)	Типом владельца является число между 1 и 4 или 255 (фиктивный процесс)
4	Flags (Флаги)	Биты, которые определяют состояние. Процесс в одно и то же время может находиться более чем в одном состоянии (см. табл. 40.4)
5	Pending (Ожидание завершения)	Смещение группы запроса блокировки, описывающей запрошенную владельцем блокировку, но еще им не полученную. Владелец может иметь не более одного ожидающего запроса в один момент времени
6	Semid (Идентификатор семафора)	Идентификатор семафора, назначенного этому пользователю. Если он может быть использован, то слово «Available» (Доступен) должно следовать после идентификатора
7	Process_id (Идентификатор процесса)	В Классическом сервере это идентификатор процесса владельца. В Суперсервере, если владельцем является соединение, база данных или транзакция, то этот владелец станет идентификатором процесса
8	UID (Идентификатор пользователя)	В POSIX это идентификатор пользователя, являющегося владельцем процесса. В Windows это всегда ноль
9	Alive \| Dead (Живой \| Мертвый)	Lock Printer вызывает подпрограмму ISC_check_process_ existence и сообщает результат
10	Flags (Флаги)	Мнемоника флагов — корректно выводится 2 в виде 0x02 (а не 0x202, как в пункте (4))
11	Requests (Запросы)	Запросы на блокировку, обработанные или ожидающие завершения, которые связаны с этим процессом. Числа последующее и предыдущее ссылаются на последующий и предыдущий элемент в очереди запросов, принадлежащих этому процессу. Числа задают смещения
12	Blocks (Группы)	Временный список блокировок (групп запросов), блокирующих другие запросы на блокировку, которыми владеет этот процесс. Этот список очищается, когда процесс сообщает, что он должен освободить или понизить уровень его блокировки в предположении, что он в состоянии это сделать

В табл. 40.4 описаны состояния, представленные разнообразными флагами владельца.

Таблица 40.4. Состояния флагов владельца

Символ	Значение	Состояние
OWN blocking	1	Владелец заблокирован. Если установлен, значит процесс имеет, по меньшей мере, один блок, который другой процесс не хочет совместно использовать
OWN scanned	2	Владелец был проверен в текущем сканировании взаимных блокировок
OWN manager	4	Системы, которые отключают сообщения между группами, имеют привилегированный Менеджер блокировок, который передает сообщения. Этот владелец является таким менеджером
OWN signal	8	Владелец должен был выдать сообщение, но не смог это сделать из-за ошибки, поэтому сигнал будет вызван менеджером блокировок
OWN wakeup	32	Владелец сообщил об освобождении блокировки
OWN starved	128	Может быть, этот поток завис. Зависание случается в многопоточной системе Solaris и означает, что владелец (процесс) выполнил более 500 неудачных попыток получения доступа к таблице блокировок для освобождения блока
OWN signaled	16	Предполагается, что сигнал был отправлен. Он обращается к флагу OWN ast flags, но был суммирован по OR с указанными флагами. Обратите внимание: похоже, что выведенное здесь шестнадцатеричное число 202 является ошибкой синтаксического анализатора

Группы блокировок (группы ресурсов)

Группы блокировок следуют после групп запросов в выходном протоколе, однако группы запросов будут проще в понимании, если мы вначале рассмотрим группы блокировок. Группа блокировок представляет блокируемый ресурс.

Типы блокировок»серии»

Блокировки ресурсов приходят различных типов или в виде серий в соответствии с типом ресурса, блокировку которого владельцы запрашивают у таблицы блокировок. В табл. 40.5 определяются и описываются различные типы блокировки ресурсов и их назначение.

Таблица 40.5. Типы ресурсов (серии)

Символ	Серия	Тип
LCK_database	1	Корень дерева блокировки. В Классическом сервере блокировка базы данных выполняется для каждого процесса, который соединяется с базой данных. Первый процесс получает исключительную блокировку. Следующий процесс сообщает о конфликте и сигнализирует первому о необходимости понижения уровня его блокировки от исключительной до уровня совместного использования. После этого все блокировки самой базы данных создаются для совместного чтения. В Суперсервере база данных получает на себя исключительную блокировку
LCK_relation	2	Индивидуальная таблица блокировки. Таблица блокировки указывает, что процесс читает и пишет в указанную таблицу в своей текущей транзакции или что он использует предложение RESERVING в операторе START TRANSACTION для сообщения своего намерения читать таблицу или писать в таблицу. В этой таблице ключевым полем является RDB$RELATION_ID. Заметьте, что оба запроса сообщают ее состояние как 2(2), указывая, что они запросили и получили блокировку на совместное чтение из таблицы
LCK_bdb	3	Индивидуальный блок буфера. Блокировка BDB является блокировкой страницы базы данных. Такие блокировки возводятся, когда два или более владельца соединяются с базой данных в Классическом сервере. Они устанавливаются, когда процесс собирается читать или писать страницу, и освобождаются, когда процесс завершает работу с буфером и требует освобождения памяти, или когда другому владельцу нужна эта страница
LCK_tra	4	Блокировка индивидуальной транзакции. Каждое действие получает исключительную блокировку для своей транзакции при ее старте. Другие владельцы могут получать пустую блокировку для чтения их состояния
LCK_rel_exist	5	Блокировка существования отношения. Предотвращает удаление таблиц, в то время как любые другие владельцы подготавливают запрос, который использует эту таблицу
LCK idx exist	6	Блокировка существования индекса. Предотвращает удаление или дезактивацию индекса, в то время как любые другие владельцы подготавливают запрос, который использует этот ресурс
LCK_attachment	7	Не используется. Блокировка соединения для поддержания блокировок записей dBase, которые могут присутствовать в пределах транзакции
LCK shadow	8	Блокировка для синхронизации добавления теневых копий (shadow). Главным образом для Классического сервера
LCK_sweep	9	Блокировка чистки для одного процесса чистки. Чистка является довольно дорогой операцией и лучше работает, если выполняется только одним потоком или соединением. Реальные «чистильщики» сохраняют исключительную блокировку в своей серии для исключения конфликтов. Эта серия используется для межпроцессных связей в Классическом сервере
LCK file_extend	10	Блокировка на синхронизацию расширения файла. Файл расширения базы данных является другой операцией, которая не выполняется таким же образом, если две транзакции пытаются выполнять операцию одновременно. Эта серия используется для межпроцессных связей в Классическом сервере
LCK retaining	11	Самая молодая транзакция, подтвержденная с сохранением контекста (commit retaining). Это используется только в VMS. Возможно, это отмечает то место, где Firebird имеет расширенную семантику блокировок для нужд VMS и, следовательно, требует специальных средств для работы с Менеджером блокировок VMS
LCK expression	12	Механизм кэширования выражения индекса. Первоначально эта серия предназначалась для описания выражений индексов — как их вычислять, как должен выглядеть результат вычислений и т.д. По разным причинам сейчас это используется при удалении индекса
LCK record locking	13	Блок на существование блокировки записи. Эта серия указывает, что была запрошена блокировка записи конкретной таблицы. Первый процесс, запрашивающий блокировку записи таблицы, также получает блокировку таблицы. Пока требуется эта блокировка, блокировки сохраняются для соединения. Когда появляется вторая транзакция, уровень блокировки таблицы снижается до совместного использования. Эта серия используется только в устаревшем коде эмуляции PC
LCK record	14	Блокировка записи. Эта серия также используется только в устаревшем коде эмуляции PC и использует RDB$DB_KEY в качестве имени блокировки
LCK_prc exist	15	Блокировка существующей процедуры. Не позволяет удалять процедуры и триггеры, пока любой другой владелец подготавливает запрос, который использует этот ресурс (или зависит от него)
LCK range_relation	16	Блокировка диапазона отношения. Опять же, эта серия используется только в коде эмуляции PC, который имеет концепцию изменения диапазонов
LCK_update_shadow	17	Блокировка синхронного изменения теневой копии. Эта серия используется для ограничения до единицы количества процессов, которые приводят к замене теневой копии или отмене теневого копирования

Варианты синтаксиса для отображения групп блокировок

Для вывода групп блокировок ресурсов заданной серии вам нужно включить номер серии в качестве аргумента:

fb_lock_print -s 2

Серия 1:база данных

Группа блокировки на рис. 40.4 представляет саму базу данных. Она имеет исключительный доступ для одного владельца- базы данных. В Классическом сервере вы увидите несколько владельцев для базы данных.

Рис. 40.4. Группа блокировки серии 1 (база данных) В табл. 40.6 объяснено, что означают записи этого отчета.

Таблица 40.6. Записи группы блокировки (ресурсов)

№	Значение	Объяснение
1	LOCK BLOCK	Идентифицирует группу описания заблокированного ресурса. Число является смещением этой группы в таблице блокировок. Оно указывает группу в другой группе, которая на нее ссылается
2	Series (Серия)	Тип ресурса, представляемого этой блокировкой. Это серия типа 1 — ресурс базы данных
3	Parent (Родитель)	Родитель для всех блокировок, связанных с базой данных. Является блокировкой самой базы данных. Единственными блокировками ресурсов, которые имеют значение 0 для родителя, являются блокировки базы данных и журналы. Ключи, которые идентифицируют блокировки в серии, имеют смысл только в контексте базы данных. Обратите внимание: несовпадения (ошибки) будут замечены внимательным читателем
4	State (Состояние)	Наивысшее текущее состояние блокировки. Блокировки имеют семь возможных состояний — см. рис. 40.1. Состояния внутренних блокировок Firebird описаны в самом начале этой главы. Пустая блокировка позволяет процессу получить блокировку ресурса, независимо от того, заблокирован ли (и как) этот ресурс кем-либо другим. Получение такой блокировки позволяет этому владельцу читать данные самой блокировки. Firebird сохраняет важную, но быстро меняющуюся информацию в блокировках- см. разд. «Использование пустой блокировки»
5	Size (Размер)	Длина в байтах той части группы блокировки, которая содержит ключ. Размер округляется до естественных границ машины (слово, двойное слово, четыре слова)
6	Length (Длина)	Фактическая длина ключа, которая из-за округления может быть меньше, чем размер
7	Data (Данные)	Только блокировки журналов и транзакций содержат данные. Данные являются 32-битовым целым числом
8	Key (Ключ)	Идентификатор заблокированного ресурса. Комбинация ключа, серии и родителя уникально идентифицирует заблокированный ресурс. Для базы данных ключом является имя базы данных (или некоторый эквивалент). Он может не выводиться в системах, которые используют целые числа как идентификаторы. Для отношения и существующей блокировки отношения ключ является идентификатором отношения. Для существующей блокировки индекса ключом является идентификатор отношения * 1000 плюс идентификатор индекса. Для блокировки теневой копии ключом является NULL, потому что существует только одно состояние теневого копирования базы данных. Для транзакции ключом является идентификатор транзакции. Для соединения ключом является идентификатор соединения
9	Hash queue (Очередь)	Начало и конец очереди хэш для ключей ресурсов. Менеджер блокировок хранит хэш-таблицу для упрощения поиска ресурсов по имени. Когда процесс запрашивает блокировку ресурса, он задает ресурс по серии, родителю и ключу. Менеджер блокировок объединяет эти значения вместе для создания ключа хэш, а затем отыскивает в списке, связанном с этим хэш-ключом, группу нужной блокировки
10	Requests (Запросы)	Вначале количество запросов на блокировку этого ресурса, затем указатели вперед и назад на группы блокировок. Имейте в виду, что обратный указатель ссылается на конец последнего блока
—	Request (Запрос)	Список запросов, включая идентификатор запрашиваемой группы, процесс, выполняющий запрос, фактическое состояние блокировки с запрашиваемым состоянием в круглых скобках. Состояние 6(6) в этом случае указывает фактическое состояние 6 и запрашиваемое состояние 6
—	Flags (Флаги)	Флаг запроса содержит биты, которые могут комбинироваться. Это: 1. Блокирование: запрос отмечается как заблокированный, если кто-то другой требует этот ресурс и не может его совместно использовать по причине текущего уровня блокировки. Блокирующий бит очищается, когда блокирующее сообщение отправляется блокирующему владельцу. 2. Ожидание завершения: это наиболее часто просматриваемый бит. Он указывает, что запрос ожидает, когда блокирующий процесс освободит эту блокировку. Вы не должны смотреть установку этого бита в блокировках BDB. 4. Конвертирование: запрос конвертируется, если процесс уже имеет блокировку этого ресурса и требует более высокого уровня блокировки, а преобразование не может быть выполнено немедленно. 8. Отмена: запрос блокировки отменяется, если запрос в режиме NO WAIT и не может быть удовлетворен немедленно или если удовлетворение запроса может привести к взаимной блокировке

Серия 2: отношение

На рис. 40.5 показана группа для ресурса отношения (таблица, просмотр).

Рис. 40.5. Группа серии 2 (ресурс отношения)

В этом случае оба владельца читают отношение. Для отношения ключевым полем является значение RDB$RELATION_ID. Заметьте, что оба запроса сообщают о своем состоянии как 2(2), указывая, что они запросили и получили блокировку на совместное чтение таблицы.

Серия 3: дескриптор BDB (страница базы данных)

На рис. 40.6 показана группа блокировки страницы базы данных (дескриптор BDB).

Рис. 40.6. Блокировка серии 3 (дескриптор BDB)

Блокировка BDB является блокировкой страницы базы данных. Такие блокировки присутствуют, когда два или более владельца подключены к базе данных в Классическом сервере. Они появляются, когда процесс собирается читать или писать страницу, и освобождаются, когда процесс выходит из буферов в кэше и должен освободить пространство или когда другому владельцу нужна эта страница. В этом примере оба владельца читают страницу 14 (ключевое значение). В Классическом сервере существует множество блокировок типа серия 3 — по одному на каждый буфер страниц в кэше для каждого независимого подключения. В Суперсервере большинство блокировок страниц выполняется сервером и не присутствует в таблице блокировок.

Серия 4: транзакция

На рис. 40.7 показана группа ресурсов транзакции.

Рис. 40.7. Группа серии 4 (ресурсы транзакции)

При запуске каждое действие получает исключительную блокировку по идентификатору его транзакции. Эта группа описывает состояние блокировок для транзакции 595. Одна транзакция ожидает завершения другой и, следовательно, может решить, является ли желаемое изменение приемлемым. Когда владелец, который имеет блокировку, уходит, его блокировки будут освобождены, а ожидающая транзакция сможет читать инвентарную страницу транзакций для определения судьбы исчезнувшей транзакции.

Серии 5, 6 и 15: существование

На рис. 40.8 показаны группы блокировок существования для отношения.

Рис. 40.8. Серии 5, 6 и 15. Группы блокировок существования

Блокировки существования отношений (серия 5) предотвращают удаление таблицы, когда какой-нибудь процесс подготавливает запрос, который использует эту таблицу. Эта блокировка является источником ошибок «Object in use» (Объект находится в использовании), которая часто появляется при попытках удаления таблиц.

Когда оператор запроса к базе данных подготавливается, компилирующий процесс получает блокировку совместного чтения отношений и индексов, включенных в этот оператор. Такие блокировки сохраняются, пока запрос не будет освобожден или не произойдет отключение от базы данных.

Когда процесс собирается удалить отношение из базы данных вместо удаления его содержимого, он должен получить исключительную блокировку на существование этого отношения. Поскольку никто не может получить исключительную блокировку на ресурс, который заблокирован для совместного чтения другим процессом, блокировки совместного чтения предотвращают разрушение отношений и, следовательно, защищают операции с метаданными от аварийного завершения подготавливаемыми запросами.

Эта блокировка существования отношения присутствует в отношении, которое имеет значением поля RDB$RELATION_ID 22.

Блокировки существования индексов предотвращают удаление или деактивацию индексов, когда другой процесс сохраняет запрос, использующий этот индекс.

Когда оператор запроса к базе данных подготавливается, компилирующий процесс также запрашивает блокировку на совместное чтение индексов, используемых в этом операторе. Такие блокировки сохраняются, пока запрос не будет освобожден или не произойдет отключения от базы данных.

Когда процесс собирается удалить или деактивировать индекс, он должен получить исключительную блокировку на существование этого индекса.

Поскольку никто не может получить исключительную блокировку на ресурс, который заблокирован для совместного чтения другим процессом, блокировки совместного чтения предотвращают разрушение отношений или индексов и, следовательно, защищают операции с метаданными от разрушения компилируемыми запросами.

Идентификатор блокировки существования индекса 12 000, который равен идентификатору отношения, умноженному на 1000, плюс идентификатор индекса. Эта блокировка сообщает о заинтересованности в существовании индекса 0 для отношения 12.

Блокировки существования процедуры в точности аналогичны блокировкам существования отношения и индекса и служат аналогичным целям. Ключ является идентификатором процедуры из системной таблицы RDB$PROCEDURES.

Серия 8: теневая копия

На рис. 40.9 показаны группы блокировок ресурса теневой копии (shadow).

Рис. 40.9. Серии 8. Группы блокировок ресурса теневой копии

Каждый процесс, который подключается к базе данных, получает блокировку на совместное чтение на состояние теневого копирования базы данных. Если процесс собирается добавить новый файл теневой копии, он должен преобразовать его блокировку в исключительное состояние, что сообщает всем другим процессам о том, что появляется новый файл теневой копии и что они должны писать изменения в этот файл. Эта серия используется для общения между процессами в Классическом сервере. Она также используется в Суперсервере, хотя не при всех эффектах, когда не требуется IPC.

Группы запросов

На рис. 40.10 показаны некоторые группы запросов. В табл. 40.7 объясняется значение записей в группе запроса.

Рис. 40.10. Некоторые группы запросов

Таблица 40.7. Записи группы запросов

№	Значение	Объяснение
1	LOCK BLOCK	Идентифицирует конкретный запрос
2	Process (Процесс)	Смещение группы процесса, которая описывает процесс, выполнивший запрос
3	Lock (Блокировка)	Смещение группы блокировки, которая описывает блокируемый ресурс
4	State (Состояние)	Состояние блокировки, которое назначено этому ресурсу
5	Mode(Режим)	Состояние, которое было запрошено для блокировки. В первых двух примерах состояние (state) такое же, как и режим (mode). Это предоставленные блокировки. Первой был предоставлен режим защищенного чтения, второй — исключительный. В третьем примере находится в состоянии ожидания, следовательно, ее состояние 0 (нет блокировки), но режим 3 (защищенное чтение)
6	Flags (Флаги)	Флаг запроса содержит биты, которые могут комбинироваться. Это: 1: блокировка; 2: ожидание; 4: преобразование; 8: отмена
7	AST	Адрес подпрограммы, которая вызывается, если кто-то другой хочет получить конфликтную блокировку на ресурс, используемый настоящим запросом. Подпрограммы понижения уровня или освобождения блокировки всегда поставляются блокировкам базы данных, состоянию теневого копирования и группам дескрипторов буферов, которые идентифицируют страницы базы данных в кэше. Уровень блокировки базы данных будет понижен от исключительного (для первого пользователя) до совместного чтения, когда второй пользователь появляется в классической архитектуре. В Суперсервере база данных сохраняет для себя исключительную блокировку. Блокировка на совместное чтение теневой копии освобождается, когда другой процесс запрашивает блокировку в исключительном режиме, следовательно, он может создавать новый файл (файлы) теневой копии. Коль скоро новые файлы будут созданы, любой другой сможет получить блокировку на совместное чтение в состоянии теневого копирования. Когда появляется конфликт для страницы базы данных, процесс, который держит страницу, немедленно ее освобождает и понижает уровень своей блокировки, если только страница не находится в процессе фактической модификации. Если да, то страница отмечается, как требующая освобождения, как только модификация будет выполнена
8	Argument (Аргумент)	Адрес чего-либо, что может понадобиться подпрограмме AST. В случае BDB это адрес структуры в процессе, которая описывает буфер. В случае блокировок базы данных и теневой копии это адрес главной группы (DBB), которая описывает базу данных

Группа истории

Менеджер блокировок отслеживает действия ввода/вывода, которые он выполнял для каждого владельца. Самые последние действия выводятся в виде двух последних элементов отчета- истории (History) и событий (Events). На рис. 40.11 показана последовательность записей истории.

Рис. 40.11. Вывод записей истории

Владельцу 11 628 предоставлена блокировка на ресурс 11 744. Владелец 12 056 ставит в очередь запрос на тот же ресурс, запрашивая его в режиме NO WAIT. Блокировка у владельца 11 628 находится в несовместимом режиме, следовательно, этому запросу будет отказано (DENY). Владелец 12 056 опять приходит и ставит в очередь другой запрос, снова запрашивая блокировку, но уже в режиме WAIT. Менеджер блокировок отправляет сообщения владельцу 11 628 по поводу ресурса 11 744. Как было сказано, владелец находится в состоянии ожидания. Через 10 секунд владелец 12 056 все еще в состоянии ожидания, поэтому Менеджер блокировок запускает сканирование взаимных блокировок. Это не дает никаких результатов, и Менеджер блокировок опять отправляет сообщения владельцу 11 628 (POST, POST, POST). В конце концов владелец 11 628 снимает блокировку, и она предоставляется владельцу 12 056.

Вывод событий содержит такую же информацию истории, но в другом формате. На рис. 40.12 показана последовательность записей истории, выводимых в части событий отчета.

В Классическом сервере запись события, похожая на «активную», показанная на рисунке, может быть причиной для беспокойства. Она указывает, что один серверный процесс получил флаг (mutex) при доступе к ресурсу, записал свой идентификатор владельца в заголовочную группу блокировки, а затем был уничтожен, в то время как он все еще хранился в таблице блокировок. Однако вторая заголовочная группа блокировки должна иметь достаточно информации, чтобы позволить второму процессу отменить все действия, частично завершенные уничтоженным процессом.

Интерактивная выборка

Интерактивные временные ряды деятельности по блокировкам генерируются, когда fb_iock_print выполняется с переключателем -i для измерения производительности Менеджера блокировок. Это моделирует UNIX-утилиту sar (System Activity Reporter, построитель отчетов системной деятельности). Отчет, показанный на рис. 40.13, выбирает каждые 4 секунды десять интервалов. Выборка на рис. 40.13 была сгенерирована в Классическом сервере Firebird при выполнении четырех локальных процессов с большим количеством конфликтов:

fb_lock_print -ia 4 10

fb_iock_print -ia «запрашивает» статистику:

1. acquire/s: среднее количество попыток в секунду обращений к таблице блокировок.

2. acqwait/s: среднее количество попыток, которым пришлось ожидать, в каждую секунду.

Рис. 40.13. Интерактивная выборка

3. %acqwait: процент попыток, которые были вынуждены ожидать.

4. acqrtry/s: среднее количество повторных обращений к таблице блокировок в секунду (в теории только для машин SMP).

5. rtrysuc/s: среднее количество успешных повторных попыток в секунду.

! ! !

СОВЕТ. В качестве подсказки, что означают столбцы в различных интерактивных отчетах, прочтите статью «Reading a Lock Print» Ann Harrison на http://www.ibphoenix.com.

. ! .

Установка конфигурации блокировки

Значения по умолчанию Менеджера блокировок должны подойти для большинства вычислительных сред. При работе, особенно в Классическом сервере, имеет смысл подрегулировать эти установки для улучшения производительности или для устранения дефицита ресурсов блокировки.

Файлы конфигурации

Файлы конфигурации размещены в корневом каталоге Firebird. Для сервера Firebird 1.5 и более поздних файл конфигурации называется firebird.conf. Для версии 1.0.x он называется ibconfig в Windows и-isc config в POSIX. Используйте текстовый редактор для открытия и редактирования этого файла.

LockAcquireSpins

Версия 1.5 и выше, файл firebird.conf.

lock_acquire_spins

Версии, предшествующие Firebird 1.5, файл iscconfig/ibconfig.

Эта установка используется только для машин SMP при выполнении Классического сервера.

В Классическом сервере в любой момент времени к таблице блокировок может иметь доступ только один клиентский процесс. Флаг управляет доступом к таблице блокировок. Клиентские процессы могут обращаться к флагу условно или безусловно. Если запрос условный, то он будет ошибочным и должен быть повторен. Если запрос безусловный, то он будет ожидать, пока не будет удовлетворен. LockAcquirespins устанавливает количество возможных попыток, если запрос к флагу условный.

Требуется целое число. Значение по умолчанию 0 (безусловный). Не существует рекомендованного минимума или максимума.

LockHashSlots

Версия 1.5 и выше, файл firebird.conf.

lock_hash_slots

Версии, предшествующие Firebird 1.5, файл iscconfig/ibconfig.

Используйте этот параметр для настройки списка хэша блокировок. При повышенной нагрузке производительность может быть улучшена увеличением области памяти под хэш для распределения списка на более короткие цепи хэша. Значением является целое число. Рекомендуется использовать простое число. Значение по умолчанию 101.

Этот параметр и LockMemSize (см. следующий раздел) должны вычисляться одновременно с использованием инструмента Lock Print. Если цепи хэш блокировок более чем в среднем 20, значит объем памяти под хэш слишком мал. Если вам надо увеличить память под хэш, вам нужно увеличить размер таблицы блокировок на тот же процент.

LockMemSize

Версия 1.5 и выше, файл firebird.conf.

any_lock_mem_size

Версии, предшествующие Firebird 1.5, файл isc_config/ibconfig.

Этот целочисленный параметр представляет количество байтов для совместно используемой памяти для таблицы Менеджера блокировок. Для Классического сервера LockMemSize задает начальное распределение, которое будет динамически увеличиваться, пока не будет исчерпана память. («Lock manager is out of room», «Исчерпана память для Менеджера блокировок» не означает, что можно отправляться пить кофе!) Значение этого параметра связано с размером кэша базы данных, поскольку каждая страница потребует отдельной блокировки в таблице. Если количество страниц базы данных в кэше установлено в большое значение, это может привести к проблемам памяти для таблицы блокировок.

В Суперсервере объем памяти, выделенный для Менеджера блокировок, не увеличивается.

Размером по умолчанию в Linux и в Solaris является 98 304 байта (96 Кбайт). В

Windows это 262 144 (256 Кбайт).

LockGrantOrder

Версия 1.5 и выше, файл firebird.conf.

lock_grant_ order

Версии, предшествующие Firebird 1.5, файл isc config/ibconfig.

Когда соединению требуется блокировка некоторого объекта, оно получает группу запроса блокировки, которая определяет объект и требуемый уровень блокировки. Группы запросов соединяются с группами блокировок в виде удовлетворенных запросов или в виде запросов, ожидающих разрешения.

Параметр LockGrantOrder является Логическим. Значение по умолчанию (1 = True) указывает, что блокировки должны предоставляться по принципу «первым пришел — первым обслужен».

Установка False (0) эмулирует поведение InterBase 3.3, когда блокировка предоставляется, как только она станет возможной. Результатом этого может оказаться то, что запросы будут «замороженными». Рассматривайте это как запрещенную установку и не пытайтесь ее использовать, если только это не требуется для тестирования некоторой модификации сервера базы данных.

LockSemCount

Версия 1.5 и выше, файл firebird.conf.

any_lock_sem_count

Версии, предшествующие Firebird 1.5, файл isc_config/ibconfig.

Это целочисленный параметр, задающий количество доступных семафоров для межпроцессной коммуникации (Inter-Process Communication, IPC) Классического сервера. Значение по умолчанию 32. Устанавливайте этот параметр для Классического сервера для увеличения или уменьшения количества доступных семафоров.

ПРИЛОЖЕНИЯ

Приложение 1. Список внешних функций

Функции условной логики

FBUDF	INULLIF(VALUE1, VALUE2)
Linux, Win32	Возвращает NULL для подвыражения, если оно преобразуется в непустое значение; иначе возвращает значение подвыражения. Применимо только для числовых типов с фиксированной точкой и только в Firebird 1.0.x. В Firebird 1.5 и выше используйте внутреннюю функцию NULLIF()
Аргументы	VALUE1: столбец или вычисляемое выражение VALUE2: константа или выражение, с которым сравнивается VALUE1. ЕСЛИ они равны, функция вернет HULL
Возвращаемое значение	NULL, если VALUE1 и VALUE равны; если равенства нет, будет возвращено VALUE 1
Замечания	INULLIFO имеет результат, эквивалентный использованию внутренней SQL-функции NULLIFO, реализованной в Firebird 1.5 и выше для числовых типов с фиксированной точкой Внешняя функция INULLIFO существует в трех реализациях: две для 32-битовых и 16-битовых типов (inullif и dnullif), а третья для 64- битовых типов (i64nullif). Если вы хотите использовать ее с любыми числовыми типами с фиксированной точкой, объявите все реализации. Объявления можно найти в скрипте fbudf.sql в каталоге /UDF вашей инсталляции Firebird. Не объявляйте реализацию i64nullif для баз данных, которые не поддерживают 64-битовые числа- например, для не перенесенной базы данных InterBase 5
Пример	Следующий оператор приведет к тому, что значение STOCK в таблице PRODUCTS будет установлено в NULL для всех строк, где оно имеет значение 0: UPDATE PRODUCTS SET STOCK = iNULLIF(STOCK, 0)
Связанные или похожие функции	См. также NULLIF() , sNullIf()

FBUDF	INVL(VALUE1, VALUE2)
Linux, Win32	Эта функция пытается повторить функцию Oracle NVL() только для числовых типов с фиксированной точкой. Она возвращает указанное непустое значение, если заданный столбец имеет значение NULL
Аргументы	VALUE1: столбец или выражение, включающее столбец. Типы с плавающей точкой не поддерживаются. При необходимости используйте в вашем выражении CAST() для преобразования значения в числовой тип. VALUE2: выражение или константа, которая будет возвращаемым значением, если VALUE1 дает NULL
Возвращаемое значение	Непустое значение. Если VALUE1 не является NULL, то оно будет возвращаемым значением; иначе будет возвращаться VALUE1. Если и VALUE1, и VALUE2 имеют значение NULL, то будет возвращено значение NULL
Замечания	Логически эта функция эквивалентна простой форме функции COALESCE О версии 1.5, когда она используется со столбцом числового типа с фиксированной точкой, а именно COALESCE(VALUE1, VALUE2) . Она должна рассматриваться как нерекомендуемая для Firebird версии 1.5 и выше. Внешняя функция iNVL() существует в трех реализациях: две для 32-битовых и 16-битовых типа (invl и dnvi), а третья для 64-битовых типов (i64nvi). Если вы хотите использовать ее с любыми числовыми типами с фиксированной точкой, объявите все реализации. Объявления можно найти в скрипте fbudf.sql в каталоге /UDF вашей инсталляции Firebird. Не объявляйте реализацию i64nvi для баз данных, которые не поддерживают 64-битовые числа — например, для не перенесенной базы данных InterBase 5
Пример	Следующий запрос возвращает 0, если STOCK имеет значение NULL: SELECT PRODUCT ID, PRODUCT NAME, INVL(STOCK, 0) FROM PRODUCTS;
Связанные или похожие функции	См. также sNVL(), iNullIf(), внутреннюю функцию COALESCE()

FBUDF	SNULLIF(VALUE1, VALUE2)
Linux, Win32	Возвращает NULL для подвыражения, если оно иначе возвращает значение этого подвыражения. Применимо только для символьных типов и должно быть использовано только в Firebird 1,0.x. В Firebird 1.5 и выше используйте NULLIFO
Аргументы	VALUE1: столбец или вычисляемое выражение. VALUE2: константа или выражение, с которым сравнивается VALUE1. ЕСЛИ они равны, SNULLIF вернет NULL
Возвращаемое значение	NULL, если VALUE1 и VALUE2 равны. Если не равны, то возвращается VALUE1
Замечания	SNOLLIF имеет результат, эквивалентный использованию внутренней функции SQL NULLIFO, реализованной в Firebird 1.5 и выше с символьными типами
Пример	Следующий запрос устанавливает значение столбца IS_REGISTERED в NULL для всех столбцов, где его значение ‘ Т’, a REGISTERED имеет значение NOLL: UPDATE ATABLE SET IS REGISTERED = SNOLLIF(IS REGISTERED, ‘T’) WHERE REGISTRATION_DATE IS NULL;
Связанные или похожие функции	См. также iNullif(). Для Firebird 1.5 и вышё см. внутреннюю функцию NULLIF()

FBUDF	SNVL(VALUE1, VALUE2)
Linux, Win32	Эта функция пытается повторить функцию Oracle NVLO только для строковых типов. Она возвращает указанное непустое значение, если заданный столбец имеет значение NULL
Аргументы	VALUE1: столбец или выражение, включающее столбец. VALUE2: выражение или константа, которая будет возвращаемым значением, если VALUE1 дает NOLL
Возвращаемое значение	Непустое значение. Если VALUE1 не является NULL, то оно будет возвращаемым значением; иначе будет возвращаться VALUE2. Если и VALUE1, и VALUE2 имеют значение NULL, ТО будет возвращено значение NULL
Замечания	Логически эта функция эквивалентна простой форме функции COALESCE() версии 1.5, когда она используется со столбцом символьного типа, а именно COALESCE(VALUE1, VALUE2). Она должна рассматриваться как нерекомендуемая для Firebird 1.5 и выше
Пример	Следующий оператор вычисляет и выводит столбец времени выполнения BIRTH YEAR для каждого студента. Если это значение вычисляется в NULL, то вместо дня рождения выводится ‘Not known’ (Неизвестно): SELECT FIRST_NAME, LAST_NAME, SNVL(CAST(EXTRACT(YEAR FROM BIRTH DATE) AS VARCHAR (9) ) , ‘ Not known’) AS BIRTH_YEAR FROM STUDENT_REGISTER;
Связанные или похожие функции	См. также iNVL(), sNullif() , внутреннюю функцию COALESCE()

Математические функции

IB_UDF	ABS(VALUE)
Linux, Win32	Возвращает абсолютное значение числа
Аргументы	VALUE является столбцом или выражением, которое совместимо с типом DOUBLE PRECISION
Возвращаемое значение	Число DOUBLE PRECISION
Пример	Этот оператор суммирует все отрицательные значения и возвращает итог в виде положительного числа: SELECT ABS(SUM(ASSET_VALUE)) AS LIABILITY FROM ASSET_REGISTER WHERE ASSET VALUE < 0;
Похожие функции	См. другую внешнюю функцию f_DoubleAbs(), которая выполняет те же действия

IB_UDF	BIN_AND(VALUE1, VALUE2)
Linux, Win32	Возвращает результат побитовой операции AND (И), выполняемой с двумя входными значениями
Аргументы	VALUE1 и VALUE2, являются столбцами или выражениями, которые преобразуются к типу SMALLINT или INTEGER
Возвращаемое значение	Значение INTEGER
Пример	SELECT BIN_AND (128,24) AS ANDED_ RESULT FROM RDB $ DATABASE;

IB_UDF	BIN_OR(VALUE1, VALUE2)
Linux, Win32	Возвращает результат двоичной (побитовой) операции OR (ИЛИ), выполняемой с двумя входными значениями
Аргументы	VALUE1 и VALUE2 являются столбцами или выражениями, которые преобразуются К типу SMALLINT или INTEGER
Возвращаемое значение	Значение INTEGER
Пример	SELECT BIN_OR(128, 24) AS ORED_RESULT FROM RDB$DATABASE;

IB_UDF	BIN_XOR(VALUE1, VALUE2)
Linux, Win32	Возвращает результат двоичной (побитовой) операции XOR (исключающее ИЛИ), выполняемой с двумя входными значениями
Аргументы	VALUE1 и VALUE2 являются столбцами или выражениями, которые преобразуются К типу SMALLINT или INTEGER
Возвращаемое значение	Значение INTEGER
Пример	SELECT BIN_XOR(128, 24) AS EXORED_RESULT FROM RDB$DATABASE;

IB_UDF	CEILING(VALUE)
Linux, Win32	Возвращает значение типа DOUBLE PRECISION, представляющее наименьшее целое, большее или равное входному значению
Аргументы	VALUE является столбцом или выражением, которое дает число типа DOUBLE PRECISION
Возвращаемое значение	Число DOUBLE PRECISION С нулевым количеством дробных знаков
Пример	SELECT CEILING (LAST_TOTAL) AS ROUND_UP_NEAREST FROM SALES_HISTORY;

IB_UDF	DIV(VALUE1, VALUE2)
Linux, Win32	Делит два целых числа и возвращает частное, отбрасывая дробную часть
Аргументы	VALUE1 и VALUE2 являются столбцами или выражениями, которые преобразуются к числам типа SMALLINT или INTEGER
Возвращаемое значение	Число DOUBLE PRECISION с нулевым количеством дробных знаков
Пример	SELECT DIV(TERM, (CURRENT_DATE — START_DATE) / 365) AS YEARS_REMAINING FROM MORTGAGE_ACCOUNT WHERE ACCOUNT_ID = 12345;

FBUDF	DPOWER(VALUE, EXPONENT)
Linux, Win32	Получает число и показатель степени и возвращает степень числа
Аргументы	EXPONENT является столбцом или выражением, которое дает число типа DOUBLE PRECISION
Возвращаемое значение	Возвращает степень числа в виде DOUBLE PRECISION
Пример	SELECT DPOWER(2.64575,2) AS NEARLY_7 FROM RDB$DATABASE;
Связанные или похожие функции	См. также SQRTO

FREEUDFLIB	F_DOUBLEABS(VALUE)
Win32	Возвращает абсолютное значение числа с плавающей точкой
Аргументы	VALUE является столбцом или выражением, которое преобразуется в число типа DOUBLE PRECISION или FLOAT
Возвращаемое значение	Положительное число типа DOUBLE PRECISION
Пример	SELECT ABS(SUM(ASSET_VALUE) ) AS LIABILITY FROM ASSET REGISTER WHERE ASSET VALUE < 0;
Связанные или похожие функции	См. также другую внешнюю функцию ABS(), которая выполняет ту же самую задачу и доступна не только на платформах Windows

FREEUDFLIB	F_ISDVISIBLEBY(VALUE1, VALUE2)
Win32	Определяет, является ли значение нацело делимым на другое значение (то есть является ли VALUE2 делителем VALUE1). Возвращает 1, если числитель(VALUE1) нацело делится на знаменатель(VALUE2); иначе возвращает 0
Аргументы	VALUE1: столбец или выражение, результатом вычисления которого является целый тип — число, которое будет делиться (числитель). VALUE2: другое целое — число, используемое в качестве знаменателя
Возвращаемое значение	Возвращает 1, если истинно, 0, если ложно
Пример	Эта функция может быть вызвана из ограничения CHECK, как в следующем примере: ALTER TABLE ORDER DETAIL ADD CONSTRAINT CHECK_MULTIPLE CHECK (ISDIVISIBLEBY (ORDER_QTY, PACK_QTY) = 1); Подобная проверка может быть использована в случае, когда для расфасованных элементов указана цена за единицу, а не за расфасовку

FREEUDFLIB	F_MODULO(VALUE1, VALUE2)
Win32	Функция возвращает остаток отделения двух целых чисел
Аргументы	VALUE1 и VALUE2 являются столбцами или выражениями, которые вычисляются в числа типа SMALLINT или INTEGER
Возвращаемое значение	Число целого типа
Замечания	Эта версия функции получения остатка от деления может быть более полезной, чем MOD(), В сложных выражениях, где возвращаемое значение является частью другого выражения, которое оперирует целыми числами.(MOD() возвращает число с плавающей точкой.)
Пример	Фрагмент из триггера: … IF (MODULO(NEW.HOURS * 100, 775) > 0.25) THEN ; NEW.OVERTIME_HOURS = MODULO(NEW.HOURS * 100, 775) / 100;
Связанные или похожие функции	См. также функцию MOD(), которая возвращает число с плавающей точкой

FREEUDFLIB	F_ROUNDFLOAT(VALUE1, VALUE2)
Win32	Округляет передаваемое значение до ближайшего значения, которое больше или меньше заданной дробной части
Аргументы	VALUE1: столбец или выражение, результатом вычисления которого является тип с плавающей точкой. Это округляемое число. VALUE2: столбец или выражение, результатом вычисления которого является тип с плавающей точкой. Это должно быть число меньше 1 и больше 0. Например, передайте значение 0.25 для округления до ближайшей четверти
Возвращаемое значение	Число с плавающей точкой, которое является VALUE1, округленным до ближайшей дробной части VALUE2
Пример	Следующий оператор вычисляет PAID_HOURS, округляя HOURS WORKED до ближайшей четверти часа: UPDATE TIMESHEET SET PAID HOURS = F_ROUNDFLOAT(HOURS WORKED, 0.25) WHERE DATE_TIMESTAMP > CURRENT_DATE — 7;
Связанные или похожие функции	См. также ROUND()

FREEUDFLIB	F_TRUNCATE(VALUE)
Win32	Усекает число с плавающей точкой до целого
Аргументы	VALUE является столбцом или выражением, результатом вычисления которого является число с плавающей точкой
Возвращаемое значение	Убирает дробную часть у VALUE и возвращает целую часть в виде целого типа
Пример	Следующий оператор вернет целое число: SELECT F_TRUNCATE(SUM(AMT_OUTSTANDING)) AS ESTIMATED_DEBTORS FROM ACCOUNT WHERE AMT_OUTSTANDING > 0;
Связанные или похожие функции	См. также TRUNCATE() и ROUND()

IB_UDF	FLOOR(VALUE)
Linux, Win32	Возвращает значение с плавающей точкой, представляющее наибольшее целое, меньшее или равное VALUE
Аргументы	VALUE является столбцом или выражением, вычисляемым в число типа DOUBLE PRECISION
Возвращаемое значение	Число типа DOUBLE PRECISION С нулевой дробной частью
Пример	SELECT FLOOR (CURRENT_DATE — START_DATE) AS DAYS_ELAPSED FROM DVD_LOANS;

IB_UDF	LN(VALUE)
Linux, Win32	Возвращает натуральный логарифм числа
Аргументы	VALUE является столбцом или выражением, вычисляемым в число типа DOUBLE PRECISION
Возвращаемое значение	Число типа DOUBLE PRECISION
Пример	SELECT LN ( (CURRENT_TIMESTAMP — LEASE_DATE) / 7) AS NLOG_WEEKS FROM LEASE_ACCOUNT ;

IB_UDF	LOG(VALUE1, VALUE2)
Linux, Win32	Возвращает логарифм по основанию x = VALUE1 числа у = VALUE2
Аргументы	VALUE1 (основание логарифма) и VALUE2 (число, с которым проводится операция) являются столбцами или выражениями, вычисляемыми в числа типа DOUBLE PRECISION
Возвращаемое значение	Число типа DOUBLE PRECISION
Замечания	Firebird 1.0.x и версии InterBase в этой функции имеют ошибку: log(x.y) ошибочно инвертирует аргументы и возвращает логарифм по основанию у числа x. Это было исправлено в версии 1.5. Имейте в виду, что существующие хранимые процедуры и код приложения могут иметь корректировки для этой ошибки
Пример	SELECT LOG(8, (CURRENT_TIMESTAMP — LEASE_DATE) /7) AS LOG_WEEKS FROM LEASE_ACCOUNT;

IB_UDF	LOG10(VALUE)
Linux, Win32	Возвращает десятичный логарифм входного числа
Аргументы	VALUE является столбцом или выражением, вычисляемым в число типа DOUBLE PRECISION
Возвращаемое значение	Число типа DOUBLE PRECISION
Пример	SELECT LOG1O( (CURRENT_TIMESTAMP — LEASE_DATE) / 7) AS LOG10_WEEKS FROM LEASE_ACCOUNT ;

IB_UDF	MODULO(VALUEl, VALUE2)
Linux, Win32	Функция возвращает остаток отделения двух целых чисел
Аргументы	VALUE1 и VALUE2 являются столбцами или выражениями, вычисляемыми в числа типа SMALLINT или INTEGER
Возвращаемое значение	Число типа DOUBLE PRECISION
Пример	Фрагмент триггера: …IF (MODULO(NEW.HOURS * 100, 775) > 25.0) THEN NEW.OVERTIME_HOURS = MODULO(NEW.HOURS * 100, 775) / 100;
Связанные или похожие функции	См. также функцию f_Modulo(), которая возвращает целое число

IB_UDF	PI()
Linux, Win32	Возвращает значение n = 3.14159…
Аргументы	Аргументы отсутствуют, однако скобки требуются
Возвращаемое значение	Значение n в виде числа DOUBLE PRECISION
Пример	SELECT PI() AS PI_VALUE FROM RDB$DATABASE;

IB_UDF	RAND()
Linux, Win32	Возвращает случайное число в диапазоне между 0 и 1. Заметьте, что эта функция не работает в Firebird 1.5
Аргументы	Аргументы отсутствуют, но скобки требуются
Возвращаемое значение	Число типа DOUBLE PRECISION
Замечания	В настоящее время используется для установления начального значения генератора
Пример	SELECT RAND() AS RANDOM NUMBER FROM RDB$DATABASE;

IB_UDF	ROUND(VALCE)
Linux, Win32	Округляет число с фиксированной точкой до ближайшего целого
Аргументы	VALUE является столбцом или выражением, вычисляемым в число с фиксированной точкой с дробными разрядами >0
Возвращаемое значение	Число целого типа
Замечания	Это полное округление. Если цифра сразу после десятичной точки больше или равна 5, то к цифре перед десятичной точкой добавляется единица, и у числа отсекаются дробные цифры. В противном случае просто отсекаются все дробные цифры
Пример	Следующий оператор составляет смету на основе результата округления произведения двух чисел NUMERIC(11,2): SELECT JOB_NO, ROUND(RATE * HOURS) + 1 AS ESTIMATE FROM QUOTATION WHERE RATE IS NOT NULL AND HOURS IS NOT NULL;
Связанные или похожие функции	См. также TRUNCATE(), F_ROUNDFLOAT()

IB_UDF	SIGN(VALUE)
Linux, Win32	Возвращает 0, 1 или -1 в зависимости от того, является ли входное значение положительным, нулем или отрицательным соответственно
Аргументы	VALUE является столбцом или выражением, вычисляемым в число типа DOUBLE PRECISION
Возвращаемое значение	Число типа DOUBLE PRECISION
Пример	Фрагмент триггера: … IF (SIGN(NEW.CURRENT_VALUE) < 1) THEN …;

IB_UDF	SQRT(VALUE)
Linux, Win32	Возвращает квадратный корень числа
Аргументы	VALUE является столбцом или выражением, вычисляемым в число типа DOUBLE PRECISION
Возвращаемое значение	Число типа DOUBLE PRECISION
Пример	Фрагмент триггера: … IF (SQRT(NEW.HYPOTENUSE) = SQRT(NEW.SIDE1) + SQRT(NEW.SIDE2)) THEN NEW.RIGHT ANGLED TRIANGLE = ‘T’;

FBUDF	TRUNCATE(VALUE)
Linux, Win32	Усекает тип с фиксированной точкой до следующего меньшего целого
Аргументы	VALUE является столбцом или выражением, вычисляемым в число с фиксированной точкой с дробными разрядами > 0
Возвращаемое значение	Число целого типа
Замечания	Как и для некоторых других функций из этой библиотеки, вам нужно два объявления, чтобы использовать 32- и 64-битовый вход. Проверьте объявления в скрипте fdudf.sql truncate и i64truncate
Пример	Следующий оператор составляет смету на основе результата усечения произведения двух чисел NUMERIC (11,2): SELECT JOB_NO, TRUNCATE (RATE * HOURS) + 1 AS ESTIMATE FROM QUOTATION WHERE RATE IS NOT NULL AND HOURS IS NOT NULL;
Связанные или похожие функции	См. также ROUND(), F_TRUNCATE()

Функции даты и времени

FBUDF	DOW(VALUE)
Linux, Win32	Получает тип TIMESTAMP и возвращает день недели (на английском языке) в качестве строки со смешанными строчными и прописными буквами
Аргументы	VALUE- столбец или выражение, результатом вычисления которого является тип TIMESTAMP
Возвращаемое значение	‘Monday’, ‘Tuesday’, ‘Wednesday’, ‘Thursday’, ‘Friday’, ‘Saturday’ или ‘Sunday’
Пример	Этот оператор добавляет четыре дня и возвращает день недели для настроенной даты: SELECT DOW(CURRENT_DATE + 4) FROM RDB$DATABASE;
Связанные или похожие функции	См. также SDOW(), внешнюю функцию EXTRACT()

FBUDF	SDOW(VALUE)
Linux, Win32	Получает тип TIMESTAMP и возвращает день недели (на английском языке) в качестве аббревиатуры со смешанными строчными и прописными буквами
Аргументы	VALUE — столбец или выражение, результатом вычисления которого является тип TIMESTAMP
Возвращаемое значение	‘Mon’, ‘Tue’, ‘Wed’, ‘Thu’, ‘Fri’, ‘Sat’ или ‘Sun’
Пример	Этот оператор добавляет четыре дня и возвращает день недели для настроенной даты: SELECT SDOW(CURRENT_DATE + 4) FROM RDB$DATABASE;
Связанные или похожие функции	См. также DOW(), внешнюю функцию EXTRACT()

FBUDF	ADDDAY(VALUE1, VALUE2)
Linux, Win32	Добавляет полное число дней к типу даты или времени и возвращает эту измененную дату в виде TIMESTAMP
Аргументы	VALUE1: столбец или выражение, результатом вычисления которого является тип даты или времени. VALUE2: количество добавляемых дней (целое число) или целое выражение
Возвращаемое значение	Настроенное TIMESTAMP (эквивалентно VALUE1 + VALUE2)
Замечания	Если входом является тип TIME, то дни будут добавлены к этому времени дня текущей даты. Если это тип DATE, ТО время дня будет полночью
Пример	Следующий оператор прибавляет 4 дня к текущей дате и возвращает полученную дату и время 0 часов 0 минут 0 секунд: SELECT ADDDAY(CURRENT_DATE, 4) FROM RDB$DATABASE;
Связанные или похожие функции	См. также ADDHOUR(), ADDMINUTE() и др.

FBUDF	ADDHOUR(VALUE1, VALUE2)
Linux, Win32	Добавляет полное количество часов к типу даты или времени и возвращает измененную дату в виде типа TIMESTAMP
Аргументы	VALUE1: столбец или выражение, результатом вычисления которого является тип даты или времени. VALUE2: количество добавляемых часов (целое число) или целое выражение
Возвращаемое значение	Настроенное значение TIMESTAMP (эквивалентно VALUE1 + (VALUE2 / 2))
Замечания	Если входное значение имеет тип TIME, ТО часы добавляются к этому времени для текущей даты. Если это тип DATE, то время дня будет полночью
Пример	Следующий оператор добавляет 10 часов и возвращает измененную дату и время: SELECT ADDHOUR(CURRENT_TIMESTAMP, 10) FROM RDB$DATABASE;
Связанные или похожие функции	См. также ADDDAY(), ADDMINUTE() и т.д.

FBUDF	ADDMILLISECOND(VALUE1, VALUE2)
Linux, Win32	Добавляет полное количество миллисекунд к типу даты или времени и возвращает измененную дату в виде типа TIMESTAMP
Аргументы	VALUE1: столбец или выражение, результатом вычисления которого является тип даты или времени.
VALUE2: количество добавляемых миллисекунд (целое число) или целое выражение	Возвращаемое значение тип TIMESTAMP
Замечания	Если входное значение имеет тип TIME, то миллисекунды добавляются к этому времени для текущей даты. Если это тип DATE, то время дня будет полночью
Пример	Следующий оператор добавляет 61 234 миллисекунды к текущему системному времени типа TIMESTAMP: SELECT ADDMILLISECOND(CURRENT_TIME, 61234) FROM RDB$DATABASE;
Связанные или похожие функции	См. также ADDDAY(), ADDMINUTE() и т.д.

FBUDF	ADDMINUTE(VALUE1, VALUE2)
Linux, Win32	Добавляет полное количество минут к типу даты или времени и возвращает измененную дату в виде типа TIMESTAMP
Аргументы	VALUE1: столбец или выражение, результатом вычисления которого является тип даты или времени. VALUE2: количество добавляемых минут (целое число) или целое выражение
Возвращаемое значение	тип TIMESTAMP
Замечания	Если входное значение имеет тип TIME, ТО минуты добавляются к этому времени для текущей даты. Если это тип DATE, то время дня будет полночью
Пример	Следующий оператор добавляет 45 минут к текущему системному времени типа TIMESTAMP: SELECT ADDMINUTE(CURRENT_TIME, 45) FROM RDB$DATABASE;
Связанные или похожие функции	См. также ADDDAY(), ADDSECOND() и т.д.

FBUDF	ADDMONTH(VALUE1, VALUE2)
Linux, Win32	Добавляет полное количество месяцев к типу даты или времени и возвращает измененную дату в виде типа TIMESTAMP
Аргументы	VALUE1: столбец или выражение, результатом вычисления которого является тип TIMESTAMP. VALUE2: количество добавляемых месяцев (целое число) или целое выражение
Возвращаемое значение	Тип TIMESTAMP, календарный месяц более поздний, чем VALUE1
Замечания	Если входное значение имеет тип TIME, то месяцы добавляются к этому времени дня для текущей даты. Если это тип DATE, ТО время дня будет полночью
Пример	Следующий оператор использует ADDMONTH() для вычисления даты завершения контракта: UPDATE CONTRACT SET FINAL_DATE = CASE CONTRACT_TERM WHEN ‘HALF-YEARLY’ THEN ADDMONTH(START_DATE, 6) WHEN ‘YEARLY’ THEN ADDMONTH(START_DATE, 12) ELSE ADDWEEK(START DATE, TRUNCATE (CONTRACT_AMT/WEEKLY_/EE) ) END WHERE START_DATE IS NOT NULL AND AMT PAID IS NOT NULL AND WEEKLY_FEE IS NOT NULL AND CONTRACTED = 1.2345;
Связанные или похожие функции	См. также ADDDAY(), ADDYEAR() и т.д.

FBUDF	ADDSECOND(VALUE1 , VALUE2)
Linux, Win32	Добавляет полное количество секунд к типу даты или времени и возвращает измененную дату в виде типа TIMESTAMP
Аргументы	VALUE1: столбец или выражение, результатом вычисления которого является тип даты или времени. VALUE2: количество добавляемых секунд (целое число) или целое выражение
Возвращаемое значение	Тип TIMESTAMP
Замечания	Если входное значение имеет тип TIME, то секунды добавляются к этому времени для текущей даты. Если это тип DATE, то время дня будет полночью
Пример	Следующий оператор добавляет 120 секунд к текущей системной дате: SELECT ADDSECOND(CURRENT_DATE, 120) FROM RDB$DATABASE;
Связанные или похожие функции	См. также ADDMONTH(), ADDMILLISECOND О и т.д.

FBUDF	ADDWEEK(VALUE1, VALUE2)
Linux, Win32	Добавляет полное количество недель к типу даты или времени и возвращает измененную дату в виде типа TIMESTAMP
Аргументы	VALUE1: столбец или выражение, результатом вычисления которого является тип даты или времени. VALUE2: количество добавляемых недель (целое число) или целое выражение
Возвращаемое значение	Настроенное значение TIMESTAMP (эквивалентно VALUE1 + (7 * VALUE2))
Замечания	Если входное значение имеет тип TIME, то недели добавляются к этому времени для текущей даты. Если это тип DATE, то время дня будет полночью
Пример	Следующий оператор вычисляет количество недель выплаты гонорара и использует это в ADDWEEK() для вычисления конечной даты контракта:
UPDATE CONTRACT	SET FINAL_DATE = ADDWEEK(START_DATE, TRUNCATE(CONTRACT_AMT/WEEKLY_FEE)) WHERE START DATE IS NOT NULL AND AMT_PAID IS NOT NULL AND WEEKLY_FEE IS NOT NULL AND CONTRACTED = 12345;
Связанные или похожие функции	См. также ADDDAY(), ADDMONTH() и т.д.

FBUDF	ADDYEAR(VALUE1, VALUE2)
Linux, Win32	Добавляет полное количество лет к типу даты или времени и возвращает измененную дату в виде типа TIMESTAMP
Аргументы	VALUE1: столбец или выражение, результатом вычисления которого является тип TIMESTAMP. VALUE2: количество добавляемых лет (целое число) или целое выражение
Возвращаемое значение	тип TIMESTAMP
Замечания	Если входное значение имеет тип TIME, то годы добавляются к этому времени дня для текущей даты. Если это тип DATE, то время дня будет полночью
Пример	Следующий оператор вычисляет конечную дату аренды, получая начальную дату: UPDATE LEASE SET FINAL_DATE = ADDYEAR(START_DATE, 5) WHERE START_DATE IS NOT NULL AND LEASE_ID = 12345;
Связанные или похожие функции	См. также ADDDAY(), ADDMONTH() и т.д.

FBUDF	GETEXACTTIMESTAMF()
Linux, Win32	Возвращает системное время в виде TIMESTAMP с точностью до ближайших миллисекунд
Аргументы	Нет аргументов
Возвращаемое значение	Тип TIMESTAMP
Замечания	Контекстная переменная даты и времени CURRENT_TIMESTAMP и предварительно определенный литерал ‘NOW’ возвращают системное время только с точностью до ближайшей секунды, GETEXACTTIMESTAMP() в настоящий момент является единственным способом получить точное системное время
Пример	Следующий оператор возвращает точное время и дату: SELECT GETEXACTTIMESTAMP() AS TSTAMP FROM RDB$DATABASE;

FBUDF	F_AGEINDAYS(VALUE1, VALUE2)
Linux, Win32	Вычисляет возраст в днях для даты(VALUE1) при ссылке на другую дату ;(VALUE2). Обычно дата, на которую ссылаются, является текущей датой, но это не обязательно должна быть она. Например, вы можете найти время, которое прошло с некоторого другого события
Аргументы	VALUE1: столбец или выражение, результатом вычисления которого является значение типа DATE или TIMESTAMP. VALUE2: столбец или выражение, результатом вычисления которого является значение типа DATE или TIMESTAMP
Возвращаемое значение	Положительное или отрицательное число типа INTEGER
Пример	SELECT FIRST_NAME, LAST_NAME, F_AGEINDAYS(DATE_OF_BIRTH, CURRENT_DATE) AS i CURRENT_AGE \| FROM MEMBERSHIP WHERE DATE_OF_BIRTH < CURRENT_DATE — (5 * 365);
Связанные или похожие функции	См. также F_AgeInDaysThreshold()

FREEUDFLIB	F_AGEINDAYSTHRESHOLD(VALUE 1, VALUE 2, MINVALUE, USEMIN, MAXVALUE, USEMAX
Win32	Вычисляет возраст в днях для даты(VALUE1) при ссылке на другую дату(VALUE2) и возвращает не это значение, а указанное минимальное число, которое меньше вычисленного значения или заданного максимального числа, которое больше вычисленного значения
Аргументы	VALUE1: столбец или выражение, результатом вычисления которого является значение типа DATE или TIMESTAMP. VALUE2: столбец или выражение, результатом вычисления которого является значение типа DATE или TIMESTAMP. Это не обязательно должна быть дата, меньшая чем VALUE1 MINVALUE: целое число. Это возвращаемое значение, если вычисленное значение будет меньше. Установите в 0, если вам нужно использовать только MAXVALUE. USEMIN: Установите в 1, если вам нужно использовать только MINVALUE. Установите USEMAX в 0, если вам нужно использовать только MINVALUE. MAXVALUE: целое число. Это возвращаемое значение, если вычисленное значение будет больше. Установите в 0, если вам нужно использовать только MINVALUE. USEMAX: целое число. Установите в 1, если вам нужно использовать MAXVALUE. Установите USEMIN в 0, если вам нужно использовать только MAXVALUE
Возвращаемое значение	Число типа INTEGER
Замечания	Если последние четыре аргумента установлены в 0, эта функция работает так же, как и F_AGETHRESHOLD
Пример	Следующий оператор вернет список, показывающий все счета с датами обязательства, меньше, чем 30 дней тому назад, вместе просроченными на 29 дней обязательствами и все с датами обязательства, более ранними, чем 90 дней тому назад, и просроченными обязательствами на 90 дней. Все остальные будут показаны с их фактическими сроками: SELECT ACCOUNT_NAME, F_AGEINDAYSTHRESHOLD(DUE_DATE, CURRENT_DATE, 29, 1, 90, 1) AS OVERDUE_AGE 1 FROM ACCOUNT;
Связанные или похожие функции	См. также AGEINDAYS()

FREEUDFLIB	F_AGEINMONTHS(VALUE1, VALUE2)
Win32	Вычисляет возраст в месяцах для даты(VALUE1) при ссылке на другую дату(VALUE2). Обычно дата, на которую ссылаются, является текущей датой, но это не обязательно должна быть она. Например, вы можете найти время, которое прошло с некоторого другого события
Аргументы	VALUE1: столбец или выражение, результатом вычисления которого является значение типа DATE или TIMESTAMP. VALUE2: столбец или выражение, результатом вычисления которого является значение типа DATE или TIMESTAMP. Не обязательно должно быть более ранней датой, чем VALUE1
Возвращаемое значение	Положительное или отрицательное число типа INTEGER
Пример	SELECT ACCOUNT NAME, F_AGEINMONTHS (DUE_DATE, CURRENT_DATE) AS OVERDUE AGE FROM ACCOUNT WHERE ACCT_BALANCE > 0 AND DUE_DATE < CURRENT_DATE — (6 * 7);
Связанные или похожие функции	См. также F_AGEINMONTHSTHRESHOLD()

FREEUDFLIB	F_AGEINMOUTHSTHRESHOLD(VALUE1, VALUE2, MIKVALUE, USEWIM, MAXVALUE, USEMAX)
Win32	Работает для F_AgelnMonths так же, как и F_AgeInDaysThreshold работает для F_AGEINDAYS
Аргументы	F_AgeInDays

FREEUDFLIB	F_AGEINWEEKS(VALUE1, VALUE2)
Win32	Вычисляет возраст в неделях для даты(VALUE1) при ссылке на другую дату(VALUE2). Обычно дата, на которую ссылаются, является текущей датой, но это не обязательно должна быть она. Например, вы можете найти время, которое прошло с некоторого другого события
Аргументы	VALUE1: столбец или выражение, результатом вычисления которого является значение типа DATE или TIMESTAMP. VALUE2: столбец или выражение, результатом вычисления которого является значение типа DATE или TIMESTAMP. Не обязательно должно быть более ранней датой, чем VALUE1
Возвращаемое значение	Положительное или отрицательное число типа INTEGER
Пример	SELECT ACCOUNT_NAME, F_AGEINWEEKS(DUE DATE, CURRENT_DATE) AS OVERDUE_AGE FROM ACCOUNT WHERE ACCT BALANCE > 0 AND DUE DATE < CURRENT_DATE — (366/2);
Связанные или похожие функции	См. также F_AGEINWEEKSTHRESHOLD()

FREEUDFLIB	F_AGEINWEEKSTHRESHOLD(VALUE 1, VALUE 2, MIHISVW, USEMIN, MAXVALUE, USEMAX)
Win32	Работает для F_AGEINWEEKS так же, как и F_AgelnDaysThreshold работает для F_AGEINDAYS

FREEUDFLIB	F_CMONTHLONG(VALUE)
Win32	Получает TIMESTAMP или DATE и возвращает название месяца (на английском языке) в виде строки
Аргументы	VALUE: столбец или выражение, результатом вычисления которого является значение типа DATE или TIMESTAMP
Возвращаемое значение	‘January’, ‘February’, ‘March’, ‘April’, ‘May’, ‘June’, ‘July’, ‘August’, ‘September’, ‘October’, ‘November’ или ‘December’
Пример	Следующий оператор добавляет 40 дней к текущей дате и возвращает название месяца полученной даты в виде строки: SELECT F CMONTHLONG(CURRENT_DATE + 40) FROM RDB$DATABASE;
Связанные или похожие функции	См. также F CMONTHSHORT(), SDOW(), внешнюю функцию EXTRACT()

FREEUDFLIB	F_CMONTHSH0RT(VALUE)
Win32	Получает TIMESTAMP или DATE и возвращает сокращенное трехсимвольное название месяца (на английском языке) в виде строки

FREEUDFLIB	F_MAXDATE(VALUE1, VALUE2)
Win32	Получает два значения или выражения типа даты или времени и возвращает более позднюю из них в виде даты и времени (TIMESTAMP В диалекте 3, DATE В диалекте 1)
Аргументы	VALUE1: столбец или выражение, результатом вычисления которого является значение типа DATE или TIMESTAMP. VALUE2: столбец или выражение, результатом вычисления которого является значение типа DATE или TIMESTAMP
Возвращаемое значение	Наиболее поздняя дата или выражение даты, преобразованное в тип TIMESTAMP

FREEUDFLIB	F_MINDATE(VALUE1, VALUE2)
Win32	Получает два значения или выражения типа даты или времени и возвращает более раннюю из них в виде даты и времени (TIMESTAMP В диалекте 3, DATE в диалекте 1)
Аргументы	VALUE1: столбец или выражение, результатом вычисления которого является значение типа DATE или TIMESTAMP VALUE2: столбец или выражение, результатом вычисления которого является значение типа DATE или TIMESTAMP
Возвращаемое значение	Наиболее ранняя дата или выражение даты, преобразованное в тип TIMESTAMP

FREEUDFLIB	F_QUARTER(VALUE)
Win32	Получает значение или выражение типа даты или времени и возвращает квартал года
Аргументы	VALUE: столбец или выражение, результатом вычисления которого является значение типа DATE или TIMESTAMP
Возвращаемое значение	Возвращает 1 для месяцев с января по март, 2 для апреля — июня, 3 для июля — сентября и 4 для октября — декабря

FREEUDFLIB	F_WOY(VALUE)
Win32	Возвращает строку, являющуюся конкатенацией года и номера недели в году
Аргументы	VALUE: столбец или выражение, результатом вычисления которого является значение типа DATE или TIMESTAMP
Возвращаемое значение	Возвращает целое число, представляющее цифры года, за которыми идут два символа, представляющие неделю года
Пример	В следующем примере возвращается 200313: SELECT WOY(‘26.03.2003’) FROM RDB$DATABASE;

Строковые и символьные функции

IB_UDF	ASCII_CHAR(VALUE)
Linux, Win32	Возвращает символ ASCII, соответствующий переданному ей десятичному значению
Аргументы	VALUE является столбцом, константой или выражением типа SMALLINT или INTEGER
Возвращаемое значение	Однобайтовый печатный или непечатный символ
Пример	Следующий оператор добавит в столбец символ перевода строки и возврата каретки для каждой строки внешней таблицы: UPDATE EXT_FILE SET EOL = ASCII_CHAR(13) \|\| ASCII_CHAR(10);

IB_UDF	ASCII_VAL(VALUE)
Linux, Win32	Возвращает значение ASCII, соответствующее переданному ей десятичному значению
Аргументы	VALUE является столбцом, константой или выражением типа CHAR
Возвращаемое значение	Целое десятичное значение ASCII
Пример	SELECT ASCII_VAL(‘&’) AS ASC_NUM FROM RDB$DATABASE;

IB_UDF	LOWER(VALUE)
Linux, Win32	Возвращает входную строку в виде символов в нижнем регистре. Работает только с символами ASCII
Аргументы	VALUE является столбцом или выражением, результатом вычисления которого является значение типа строки ASCII длиной 32 765 байт или меньше
Возвращаемое значение	CHAR(n) или VARCHAR(n) того же размера, что и входная строка
Замечания	Эта функция может получать и возвращать до 32 767 символов, ограничение на символьные строки Firebird
Пример	Следующий оператор вернет строку ‘come and sit at my table’: SELECT LOWER(‘Come and sit at MY TABLE’) AS L_STRING FROM RDB$DATABASE;

IB_UDF	LPAD(VALUE, LENGTH, IN_CHAR)
Linux, Win32	Присоединяет указанный символ IN CHAR к началу входной строки VALUE до тех пор, пока длина результирующей строки не станет равной заданному числу LENGTH
Аргументы	VALUE: столбец или выражение, результатом вычисления которого является значение типа строки не длиннее, чем (32767 — LENGTH) байт. LENGTH: константа или выражение типа целого. IN CHAR: один символ, который используется в качестве символа заполнителя
Возвращаемое значение	CHAR(n) или VARCHAR(n), где n имеет значение входного аргумента LENGTH
Замечания	Эта функция может получать и возвращать до 32 767 символов, ограничение на символьные строки Firebird
Пример	Следующий оператор вернет строку ‘ ##########RHUBARB ‘: SELECT LPAD(‘RHUBARB’, 17, ‘#’) AS LPADDED_STRING FROM RDB$DATABASE;
Связанные или похожие функции	См. также RPAD()

IB_UDF	LTRIM(VALUE)
Linux, Win32	Удаляет начальные пробелы из входной строки
Аргументы	VALUE — столбец или выражение, результатом вычисления которого является значение типа строки длиной не более 32 767 байт
Возвращаемое значение	CHAR(N) или VARCHAR(n) без начальных пробельных символов
Замечания	Эта функция может принимать 32 765 байт, включая пробельные символы, ограничение для символьных строк Firebird
Пример	Следующий фрагмент триггера BEFORE INSERT будет удалять начальные пробелы из входной строки: NEW.CHARACTER_COLUMN = LTRIM(NEW.CHARACTER_COLUMN) ;
Связанные или похожие функции	См. также RTRIM(), F_RTRIM(), F_LRTRIM()

FBUDF	SRIGHT(VALUE, LENGTH)
Linux, Win32	Возвращает подстроку для VALUE, являющуюся правой частью строки VALUE длиной LENGTH символов
Аргументы	Нет
Возвращаемое значение	VALUE: столбец или выражение, результатом вычисления которого является значение типа строки длиной не более 32 767 байт. LENGTH: константа или выражение типа целого
Замечания	Эта функция может принимать 32 765 байт, ограничение для символьных строк Firebird
Пример	Следующий оператор вернет строку ‘fox jumps over the lazy dog’: SELECT SRIGHT(‘The quick brown fox jumps over the lazy dog.’, 28) AS R_STRING FROM RDB$DATABASE;
Связанные или похожие функции	См. также SUBSTRO , SUBSTRLEN(), внутреннюю функцию SUBSTRING()

IB_UDF	RPAD(VALUE, LENGTH, IN_CHAR)
Linux, Win32	Присоединяет указанный символ IN_CHAR К концу входной строки VALUE до тех пор, пока длина результирующей строки не станет равной заданному числу LENGTH
Аргументы	VALUE: столбец или выражение, результатом вычисления которого является значение типа строки не длиннее, чем (32765 — LENGTH) байт. LENGTH: константа или выражение типа целого. IN CHAR один символ, который используется в качестве символа заполнителя
Возвращаемое значение	CHAR(n) или VARCHAR(n), где n имеет значение входного аргумента LENGTH
Замечания	Эта функция может получать и возвращать до 32 765 символов, ограничение на символьные строки Firebird
Пример	Следующий оператор вернет строку ‘ Framboise**********’: SELECT RPAD (‘Framboise’, 20, ‘ ‘ ) AS RPADDED_STRING FROM RDB$DATABASE;
Связанные или похожие функции	См. также LPADO

IB_UDF	RTRIM(VALUE)
Linux, Win32	Удаляет конечные пробелы из входной строки
Аргументы	VALUE- столбец или выражение, результатом вычисления которого является значение типа строки длиной не более 32 765 байт
Возвращаемое значение	CHAR(n) или VARCHAR(n) без конечных пробельных символов
Замечания	Эта функция может принимать 32 765 байт, включая пробельные символы, значение для символьных строк Firebird
Пример	Следующий фрагмент триггера BEFORE INSERT будет удалять конечные пробелы из входной строки: . . . NEW.CHARACTER_COLUMN = RTRIM (NEW.CHARACTER_COLUMN);
Связанные или похожие функции	см. также LTRIM(), F_LRTRIM()

IB_UDF	STRLEN(VALUE)
Linux, Win32	Возвращает длинустроки
Аргументы	VALUE — столбец или выражение, результатом вычисления которого является значение типа строки длиной не более 32 765 байт
Возвращаемое значение	Целое число, длина (счетчик) символов в строке
Замечания	Эта функция может принимать 32 765 байт, включая пробельные символы, ограничение для символьных строк Firebird
Пример	Следующий фрагмент модуля PSQL присваивает длину столбца локальной переменной: . . . DECLARE VARIABLE LEN INTEGER; . . . SELECT COL1, COL2, COL3 FROM ATABLE INTO :VI, :V2, :V3; LEN = STRLEN(V3);
Связанные или похожие функции	См. также SUBSTRLEN()

IB_UDF	SUBSTR(VALUE, P0S1, P0S2)
Linux, Win32	Возвращает строку, состоящую из позиций с POSI по POS2 включительно. Если POS2 превышает длину строки, то функция вернет все символы с позиции POSI до конца строки
Аргументы	VALUE: столбец или выражение, результатом вычисления которого является значение типа строки. POSI, POS2: столбец или выражение, результатом вычисления которого является целый тип
Возвращаемое значение	Строка
Замечания	Если вы переносите приложение, написанное для InterBase, имейте в виду, что эта версия SUBSTRO отличается от реализованной в поставляемой Borland библиотеке ib_udf функции SUBSTRO, которая возвращает NULL, если POS2 выходит за пределы входной строки. Эта функция может принимать 32 765 байт, включая пробельные символы, ограничение для символьных строк Firebird
Пример	Следующий оператор убирает первые три символа у строки COLUMNB и устанавливает ее значение в строку, начинающуюся с позиции 4 и заканчивающуюся позицией 100. Если строка заканчивается до позиции 100, результатом будут все символы от позиции 4 до конца строки: UPDATE ATABLE SET COLUMNB = SUBSTR(COLUMNB, 4, 100) WHERE…
Связанные или похожие функции	См. также SUBSTRLEN(), RTRIM(), внутреннюю функцию SUBSTRING()

IB_UDF	SUBSTRLEN(VALUE, STARTPOS, LENGTH)
Linux, Win32	Возвращает строку длиной LENGTH, начинающуюся с позиции STARTPOS. Длина этой строки будет меньше, чем LENGTH, если начальная позиция плюс длина превышают длину исходной строки
Аргументы	VALUE: столбец или выражение, результатом вычисления которого является значение типа строки не длиннее 32 765 байт. STARTPOS: столбец или выражение, результатом вычисления которого является целый тип. LENGTH: столбец или выражение, результатом вычисления которого является целый тип
Возвращаемое значение	Строка
Замечания	Эта функция может принимать 32 765 байт, включая пробельные символы, ограничение для символьных строк Firebird
Пример	Следующий оператор берет значение столбца и изменяет его, удаляя первые три символа и удаляя после этого все конечные символы, если оставшаяся часть строки длиннее 20 символов: UPDATE ATABLE SET COLUMNB = SUBSTRLEN(COLUMNB, 4, 20) WHERE…
Связанные или похожие функции	См. также SUBSTRO, RTRIMO, внутреннюю функцию SUBSTRING()

FREEUDFLIB	F_CRLF
Win32	Возвращает строку Windows возврат каретки/начало строки ASCII(13) \|\| ASCII(10)
Аргументы	Нет
Возвращаемое значение	Строка в стиле языка С (завершается нулем)
Пример	Следующий оператор добавляет Windows-маркеры конца строки в столбец таблицы (например, во внешнюю таблицу для экспорта в другое приложение): INSERT INTO EXTABLE(COLUMN1, COLUMN2, EOL) VALUES (99, ‘An item of data’, CRLF());

FREEUDFLIB	F_FINDW0RD(VALUE, N)
Win32	Начиная с указанной позиции n, возвращает слово, содержащее символ этой позиции и следующие символы вплоть до следующего символа пробела
Аргументы	VALUE: столбец или выражение, результатом вычисления которого является значение типа строки. N: целый тип, указывающий на позицию (начинающуюся с нуля) в строке, где находится требуемое слово
Возвращаемое значение	Строка
Замечания	Рассматривайте строки, передаваемые в F_FINDWORD(), как массивы символов, начинающиеся с индекса 0
Пример	Следующий оператор возвращает слово ‘pie’: SELECT F_FINDWORD(‘I never tasted pie like Mom used to make’, 15) FROM RDB5DATABASE;

FREEUDFLIB	F_LEFT(VALUE, N)
Win32	Возвращает первые N символов из входной строки VALUE
Аргументы	VALUE: столбец или выражение, результатом вычисления которого является значение типа строки. N: целый тип, указывающий количество возвращаемых символов из левой части VALUE
Возвращаемое значение	Строка из N символов
Пример	Следующий оператор возвращает строку ‘I never tasted pie’: SELECT F_LEFT(‘I never tasted pie like Mom used to make’, 18) FROM RDB$DATABASE;
Связанные или похожие функции	См. также SUBSTRLEN(), SUBSTRO , внутреннюю функцию SUBSTRING()

FREEUDFLIB	F_LINEWRAP(VALUE, STARTPOS, WIDTH)
Win32	Получая начальную позицию (STARTPOS) в строке(VALUE) и размер (WIDTH), возвращает часть строки VALUE, начиная с позиции STARTPOS, которая занимает пространство в WIDTH символов
Аргументы	VALUE: столбец или выражение, результатом вычисления которого является значение типа строки. STARTPOS: целый тип, указывающий на позицию (начинающуюся с нуля) в строке, где находится возвращаемая строка. WIDTH: целый тип, задающий ширину столбца (печатаемого/отображаемого), которую должна занимать возвращаемая строка
Возвращаемое значение	Строка из WIDTH (или меньше) символов
Замечания	Рассматривайте строки, передаваемые в F_LINEWRAP(), как массивы символов, начинающиеся с индекса 0
Пример	Следующий оператор возвращает строку ‘which, taken at the flood’: SELECT F_WORDWRAP(‘There is a tide in the affairs of men which, taken at the flood, leads on to good fortune.’, 38, 25) FROM RDB$DATABASE;

FREEUDFLIB	F_LRTRIM(VALUE)
Win32	Удаляет из строки все начальные и конечные пробелы
Аргументы	VALUE: столбец или выражение, результатом вычисления которого является значение типа строки
Возвращаемое значение	Строка с отсутствующими начальными и конечными пробелами
Пример	Следующий оператор возвращает строку ‘lean and mean’: SELECT F_LRTRIM(‘ lean and mean’) FROM RDB$DATABASE;
Связанные или похожие функции	См. также LTRIM(), RTRIM()

FREEUDFLIB	F_PROPERCASE(VALUE)
Win32	Преобразует строку в «правильный» вид, то есть берет каждое слово и заменяет первый символ на эквивалент в верхнем регистре, переводя каждый другой символ слова в нижний регистр
Аргументы	VALUE: столбец или выражение, результатом вычисления которого является значение типа строки
Возвращаемое значение	Строка, подобная следующей: ‘Now Is The Time For All Good Men To Come To The Aid Of The Party’
Замечания	Хотя эта функция и удобна для некоторых задач, она имеет ряд ограничений. В частности, не может правильно трактовать такие имена, как dOliveira, OHalloran или MacDonald
Пример	Следующий оператор вернет строку ‘Eric S. Raymond’: SELECT F_PROPERCASE(‘ERIC S. RAYMOND’) FROM RDB$DATABASE;
Связанные или похожие функции	.I См. также LOWER(), UPPER()

Функции BLOB^[159]

FBUDF	STRING2BLOB(VALUE)
Linux, Win32	Принимает поле строки (столбец, переменную, выражение) и возвращает текст BLOB
Аргументы	VALUE: столбец или выражение, результатом вычисления которого является значение типа VARCHAR 300 символов или меньше
Возвращаемое значение	Текст BLOB
Замечания	В большинстве случаев нет необходимости вызывать эту функцию. Firebird напрямую принимает строки в качестве входных данных для BLOB
Пример	Следующий фрагмент модуля PSQL выполняет конкатенацию двух строк и конвертирует результат в текст BLOB: . . . DECLARE VARIABLE V_COMMENTl VARCHAR(250); DECLARE VARIABLE V_COMMENT2 VARCHAR(45); DECLARE VARIABLE V_MEMO VARCHAR(296) = ‘ ‘; . . . SELECT<. . .другие поля. . .>, COMMENT1, COMMENT2 FROM APPLICATION WHERE APPLICATION_ID = :APP_ID INTO <…другие переменные…>, :V_COMMENTl, V_COMMENT2; IF (V_COMMENT1 IS NOT NULL) THEN V_MEMO = V_COMMENT1; IF (V_COMMENT2 IS NOT NULL) THEN BEGIN IF (V_MEMO = ») THEN V_MEMO = V_C0MMENT2; ELSE V_MEM0 = V_MEMO \|\|’ ‘ \|\| V_COMMENT2; END IF (V_MEMO <> ‘ ‘) THEN INSERT INTO MEMBERSHIP( FIRST_NAME, LAST_NAME, APP_ID, BLOB_MEMO) VALUES ( :FIRST_NAME, :LAST_NAME, :APP_ID, STRING2BLOB (:V_MEMO) ) ; . . .
Связанные или похожие функции	См. также F_BLOBASPCHAR()

FREEUDFLIB	F_BLQBMAXSEGENTLENGTH(VALUE)
Win32	Принимаемая ссылка на BLOB В памяти возвращает количество сегментов для его хранения
Аргументы	VALUE является идентификатором столбца BLOB В таблице
Возвращаемое значение	Целое число, являющееся количеством сегментов
Пример	SELECT F_BLOBSEGMENTCOUNT(BLOB_MEMO) AS SEGMENT_COUNT FROM MEMBERSHIP WHERE MEMBER_ID = ….;
Связанные или похожие функции	См. также F_MAXBLOBSEGMENTSIZE(), F_BLOBSIZE()

FREEUDFLIB	F_BLOBSIZE(VALUE)
Win32	Принимаемая ссылка на BLOB в памяти возвращает размер в байтах
Аргументы	VALUE является идентификатором столбца BLOB в таблице
Возвращаемое значение	Целое число, являющееся размером BLOB в байтах
Пример	SELECT F_BLOBSIZE(BLOB_MEMO) AS SIZE_OF_MEMO FROM MEMBERSHIP WHERE MEMBER_ID = ;
Связанные или похожие функции	См. также F_BLOBSEGMENTCOUNT(), F_BLOBMAXSEGMENTSIZE()

FREEUDFLIB	F_BLOBASPCHAR(VALUE)
Win32	Принимает ссылку на поле BLOB (столбец или переменная) и возвращает [ его содержимое в виде строки, завершаемой нулем
Аргументы	VALUE является ссылкой на столбец или переменную BLOB
Возвращаемое значение	Строка, завершаемая нулем
Замечания	Используйте эту функцию только для тех BLOB, о которых вы точно знаете, ; что их размер не превышает максимальную длину типа VARCHAR (32 765 байт). Учитывайте увеличенный размер в байтах в BLOB, хранящих многобайтовые символы
Пример	SELECT F_BLOBASPCHAR(BLOB_MEMO) AS MEMO_STRING FROM MEMBERSHIP WHERE MEMBER_ID = ;
Связанные или похожие функции	См. также STRING2BLOB()

FREEUDFLIB	F_BLQBLEFT(VALUE, N)
Win32	Получает ссылку на поле BLOB (столбец или переменная) и возвращает первые n символов
Аргументы	VALUE: идентификатор столбца или переменной BLOB. N: максимальное количество возвращаемых символов. Не должно превышать максимальной длины для VARCHAR (32 765 байт)
Возвращаемое значение	Завершаемая нулем строка длиной N или менее символов
Замечания	Учитывайте увеличенный размер в байтах в BLOB, хранящих многобайтовые символы
Пример	SELECT F_BLOBLEFT(BLOB_MEMO, 20) AS MEMO_START FROM MEMBERSHIP WHERE MEMBER_ID = ;
Связанные или похожие функции	См. также F_BLOBMID(), F_BLOBRIGHT()

FREEUDFLIB	F_BLOBLINE(VALUE, N)
Win32	Получает ссылку на поле BLOB (столбец или переменная) и возвращает строку за номером N
Аргументы	VALUE: идентификатор столбца или переменной BLOB. N: номер строки BLOB. Первая строка рассматривается как строка номер 1
Возвращаемое значение	Завершаемая нулем строка
Замечания	Используйте эту функцию только для тех BLOB, которые содержат строки, разделенные символами CRLF (возврат каретки, перевод строки). Не используйте ее, если вы не уверены, что строки не превышают максимальную длину для типа VARCHAR (32 765 байт). Учитывайте увеличенный размер в байтах в BLOB, хранящих многобайтовые символы
Пример	SELECT F_BLOBLINE(BLOB_MEMO, 20) AS MEMO_LINE20 FROM MEMBERSHIP WHERE MEMBER ID — ….;
Связанные или похожие функции	См. также F_BLOBMID(), F_BLOBRIGHT()

FREEUDFLIB	F_BLOBMID(VALUE, STARTPOS, N)
Win32	Получает ссылку на поле BLOB (столбец или переменная) и возвращает N символов, начиная с позиции STARTPOS
Аргументы	VALUE: идентификатор столбца или переменной BLOB. STARTPOS: позиция первого символа в возвращаемой строке. N: максимальное количество возвращаемых символов. Не должно превышать максимальной длины для VARCHAR (32 765 байт)
Возвращаемое значение	Завершаемая нулем строка длиной N или менее символов
Замечания	Учитывайте увеличенный размер в байтах в BLOB, хранящих многобайтовые символы
Пример	SELECT F_BLOBMID(BLOB_MEMO, 140, 20) AS MEMO_SUBSTRING FROM MEMBERSHIP WHERE MEMBER_ID = . . .;
Связанные или похожие функции	См. также F_BLOBRIGHT(), F_BLOBLEFT()

FREEUDFLIB	F_BLOBRIGHT(VALUE, N)
Win32	Получает ссылку на поле BLOB (столбец или переменная) и возвращает последние N символов
Аргументы	VALUE: идентификатор столбца или переменной BLOB. N: максимальное количество возвращаемых символов. Не должно превышать максимальной длины для VARCHAR (32 765 байт)
Возвращаемое значение	Завершаемая нулем строка длиной N или менее символов
Замечания	Учитывайте увеличенный размер в байтах в BLOB, хранящих многобайтовые символы
Пример	SELECT F_BLOBRIGHT(BLOB_MEMO, 20) AS MEMO_END FROM MEMBERSHIP WHERE MEMBER_ID = ;
Связанные или похожие функции	См. также F BLOBMIDO, F BLOBLEFTO

FREEUDFLIB	F_BLOBBINCMP(VALUE1, VALUE2)
Win32	Выполняет двоичное сравнение двух полей BLOB (столбцы или переменные) и возвращает значение, указывающее, являются ли они одинаковыми
Аргументы	VALOE1 и VALUE2 являются идентификаторами двух столбцов или переменных BLOB, для которых выполняется сравнение
Возвращаемое значение	1 (истина), если поля одинаковы, и 0 в противном случае

Тригонометрические функции

IB_UDF	ACOS(VALUE)
Linux, Win32	Вычисляет арккосинус для числа между -1 и 1. Если число выходит за эти границы, то возвращается NaN
Аргументы	VALUE: столбец или выражение, совместимое со знаковым или беззнаковым числом DOUBLE PRECISION, которое является допустимым значением косинуса
Возвращаемое значение	Число DOUBLE PRECISION в градусах
Пример	Следующий фрагмент триггера преобразует значение косинуса в градусы: . . . IF (NEW.RAW_VALUE IS NOT NULL) THEN NEW.READING1 = ACOS(NEW.RAW_VALUE);
Связанные или похожие функции	См, также COS(), COSH() и другие тригонометрические функции

IB_UDF	ASIN(VALUE)
Linux, Win32	Вычисляет арксинус для числа между -1 и 1. Если число выходит за этот диапазон, то возвращается NaN
Аргументы	VALUE: столбец или выражение, совместимое со знаковым или беззнаковым числом DOUBLE PRECISION, которое является допустимым значением синуса
Возвращаемое значение	Число DOUBLE PRECISION в градусах
Пример	Следующий фрагмент триггера преобразует значение синуса в градусы: . . . IF (NEW.RAW_VALUE IS NOT NULL) THEN NEW.READING1 = ACOS(NEW.RAW VALUE);
Связанные или похожие функции	См. также SIN(), SINH() и другие тригонометрические функции

IB_UDF	ATAH(VALUE)
Linux, Win32	Возвращает арктангенс входного значения
Аргументы	VALUE: столбец или выражение, совместимое со знаковым или беззнаковым числом DOUBLE PRECISION, которое является допустимым значением тангенса
Возвращаемое значение	Число DOUBLE PRECISION в градусах

Пример	Следующий фрагмент триггера преобразует значение тангенса в арктангенс (в градусах): IF (NEW.RAW_VALUE IS NOT NOLL) THEN NEW.READINGL = ATAN(NEW.RAW_VALUE);
Связанные или похожие функции	См. также ATAN2(). TAN() , TANH() и другие тригонометрические функции

IB_UDF	ATAH2(VALUE1, VALUE2)
Linux, Win32	Возвращает значение, являющееся арктангенсом в градусах, вычисляемое как арктангенс результата деления одного тангенса на другой
Аргументы	VALUE 1 и VALUE2 являются числовыми столбцами или выражениями, вычисляемыми в число DOUBLE PRECISION, которое является допустимым значением тангенса
Возвращаемое значение	Число DOUBLE PRECISION, являющееся арктангенсом VALUE1 / VALUE2 В градусах
Пример	Следующий фрагмент модуля PSQL сохраняет значение, которое является углом в градусах, как арктангенс результата деления одного тангенса на другой: UPDATE HEAVENLY_HAPPENINGS SET INCREASE_RATIO = ATAN2 (INITIAL TAN, FINAL TAN) WHERE HAPPENING_ID = :happening_id;
Связанные или похожие функции	См. также ATAN(), TAN(), TANH()

IB_UDF	COS(VALUE)
Linux, Win32	Возвращает косинус значения VALUE
Аргументы	VALUE: столбец или выражение, совместимое со знаковым или беззнаковым числом DOUBLE PRECISION, преобразуемым к значению (в градусах) от -263 до 263
Возвращаемое значение	Число DOUBLE PRECISION или 0, если входное значение выходит за границы диапазона
Замечания	Если VALUE больше или равно 263 либо меньше или равно -263, то произойдет потеря значения, а функция сгенерирует ошибку a TLOSS и вернет 0
Пример	Следующий фрагмент триггера вычисляет и сохраняет косинус угла в градусах: IF (NEW.READINGl IS NOT NULL) THEN NEW.RDG_COSINE = COS(NEW.READINGl);
Связанные или похожие функции	См. также SIN(), cos(), ACOS(), COSH()

IB_UDF	COSH(VALUE)
Linux, Win32	Возвращает гиперболический косинус значения VALUE
Аргументы	VALUE: столбец или выражение, совместимое со знаковым или беззнаковым числом DOUBLE PRECISION, преобразуемым к значению (в градусах) от -263 до 263
Возвращаемое значение	Число DOUBLE PRECISION или 0, если входное значение выходит за границы диапазона
Замечания	Если VALUE больше или равно 263 либо меньше или равно -263, то произойдет потеря значения, а функция сгенерирует ошибку a_TLOSS и вернет 0
Пример	Следующий фрагмент триггера вычисляет и сохраняет косинус угла в градусах: IF (NEW.READING1 IS NOT NULL) THEN NEW.RDG_COS_HYP = COSH(NEW. READING1) ;
Связанные или похожие функции	См. также SINH(), TANH() и другие тригонометрические функции

IB_UDF	COT(VALUE)
Linux, Win32	Возвращает котангенс значения VALUE
Аргументы	VALUE: столбец или выражение, совместимое со знаковым или беззнаковым числом DOUBLE PRECISION, преобразуемым к значению (в градусах) от -263 до 263
Возвращаемое значение	Число DOUBLE PRECISION или 0, если входное значение выходит за границы диапазона
Замечания	Если VALUE больше или равно 263 либо меньше или равно -263, то произойдет потеря значения, а функция сгенерирует ошибку a_TLOSS и вернет 0
Пример	Следующий фрагмент триггера вычисляет и сохраняет котангенс угла в градусах: IF (NEW.READINGl IS NOT NULL) THEN NEW.RDG_COTAN = COT(NEW.READINGl);
Связанные или похожие функции	См. также TAN(), ATAN(), TANH()

IB_UDF	SIN(VALUE)
Linux, Win32	Возвращает синус значения VALUE
Аргументы	VALUE: столбец или выражение, совместимое со знаковым или беззнаковым числом DOUBLE PRECISION, преобразуемым к значению (в градусах) от -263 до 263
Возвращаемое значение	Число DOUBLE PRECISION или 0, если входное значение выходит за границы диапазона
Замечания	Если VALUE больше или равно 263 либо меньше или равно -263, то произойдет потеря значения, а функция сгенерирует ошибку A TLOSS и вернет 0
Пример	Следующий фрагмент триггера вычисляет и сохраняет синус угла в градусах: IF (NEW.READINGl IS NOT NULL) THEN NEW.RDG_SINE = SIN (NEW.READINGl) ;
Связанные или похожие функции	См. также cos(), ASIN(), SINH()

IB_UDF	HSIN(VALUE)
Linux, Win32	Возвращает гиперболический синус значения VALUE
Аргументы	VALUE: столбец или выражение, совместимое со знаковым или беззнаковым числом DOUBLE PRECISION, преобразуемым к значению (в градусах) от -263 до 263
Возвращаемое значение	Число DOUBLE PRECISION или 0, если входное значение выходит за границы диапазона
Замечания	Если VALUE больше или равно 263 или меньше или равно -263, то произойдет потеря значения и функция сгенерирует ошибку a_TLOSS и вернет 0
Пример	Следующий фрагмент триггера вычисляет и сохраняет гиперболический синус угла в градусах: IF (NEW.READINGl IS NOT NULL) THEN NEW.RDG_SIN_HYP = SINH(NEW.READINGl);
Связанные или похожие функции	См. также SIN(), TANH(), COSH()

IB_UDF	TAN(VALUE)
Linux, Win32	Возвращает тангенс значения VALUE
Аргументы	VALUE: столбец или выражение, совместимое со знаковым или беззнаковым числом DOUBLE PRECISION, преобразуемым к значению (в градусах) от -263 до 263
Возвращаемое значение	Число DOUBLE PRECISION или 0, если входное значение выходит за границы диапазона
Замечания	Если VALUE больше или равно 263 или меньше или равно -263, то произойдет потеря значения и функция сгенерирует ошибку a_TLOSS и вернет 0
Пример	Следующий фрагмент триггера вычисляет и сохраняет тангенс угла в градусах: IF (NEW.READINGl IS NOT NULL) THEN NEW.RDG_TAN = TAN (NEW. READINGl) ;
Связанные или похожие функции	См. также сот(), ATAN(), TANH()

IB_UDF	TANH(VALUE)
Linux, Win32	Возвращает гиперболический тангенс значения VALUE
Аргументы	VALUE: столбец или выражение, совместимое со знаковым или беззнаковым числом DOUBLE PRECISION, преобразуемым к значению (в градусах) от -263 до 263
Возвращаемое значение	Число DOUBLE PRECISION или 0, если входное значение выходит за границы диапазона
Замечания	Если VALUE больше или равно 263 либо меньше или равно -263, то произойдет потеря значения, а функция сгенерирует ошибку a TLOSS и вернет 0
Пример	Следующий фрагмент триггера вычисляет и сохраняет гиперболический тангенс угла в градусах: IF (NEW.READINGl IS NOT NULL) THEN NEW.RDG_TAN_HYP = TANH (NEW. READINGl) ;
Связанные или похожие функции	См. также TAN(), ATAN()

Подпрограммы форматирования данных

FREEUDFLIB	F_DOLLARVAL(VALUE)
Linux, Win32	Форматирует значение числа с фиксированной точкой в формат валюты, например, в 99 999 999.99, подходящий для конкатенации с символами валюты и другими украшениями
Аргументы	VALUE: столбец или выражение, которое вычисляется в число типа DOUBLE PRECISION или FLOAT
Возвращаемое значение	Строка переменной длины
Замечания	Необходимо быть внимательным по отношению к точности входного числа, особенно в случае, когда оно получается в результате вычисления. Можно ожидать неверных результатов, когда значение передается значениям CHAR или VARCHAR, размер которых слишком мал для приема этого значения
Пример	SELECT ‘$’ \|\| F_DOLLARVAL (CAST (SUM (PURCHASE_AMT) AS DOUBLE PRECISION)) \|\|’ USD’ AS TOTALISPEND FROM MEMBER ACCOUNT WHERE MEMBER_ID = 440099;
Связанные или похожие функции	См. также F_FixedPoint()

FREEUDFLIB	F_FIXEDPOIRT(VALUE1, VALUE2)
Win32	Форматирует передаваемое значение VALUE1 как строку с фиксированной точкой с количеством дробных знаков VALUE2
Аргументы	VALUE1: столбец или выражение, которое вычисляется в число с плавающей точкой: преобразуемое число. VALUE2: константа или выражение, которое вычисляется в целый тип: количество знаков после десятичной точки для отображения в выходных данных
Возвращаемое значение	Строка переменной длины
Замечания	Необходимо быть внимательным по отношению к точности входного числа, особенно в случае, когда оно получается в результате вычисления. Можно ожидать неверных результатов, когда значение передается значениям CHAR или VARCHAR, размер которых слишком мал для приема этого значения
Пример	SELECT ‘TOTALYARDAGE: ‘ \|\| F_FIXEDPOINT(SUM(YARDAGE), 3) \|\| ‘ yds’ AS TOTAL YARDAGE FROM PIECE_GOODS WHERE PRODUCT_ID = 100;
Связанные или похожие функции	См. также FjDollarValue()

IB_UDF	F_GENERATESHDXINDEX(VALUE)
Win32	Получая строку VALUE, вычисляет ее значение SOUNDEX
Аргументы	VALUE: столбец или выражение, вычисляемое в символьный тип, либо имя, для которого генерируется SOUNDEX
Возвращаемое значение	Шестисимвольный индекс SOUNDEX
Замечания	Простой алгоритм SOUNDEX используется для вычисления индекса SOUNDEX, он генерирует алгоритмический код. Вам не нужно понимать этот алгоритм для реализации индексирования SOUNDEX
Пример	Следующий фрагмент триггера BEFORE INSERT демонстрирует, как эта функция может быть использована для автоматического сохранения столбца SOUNDEX в качестве столбца поиска в регистре участников: IF (NEW.LAST_NAME IS NOT NULL) THEN NEW. SOUNDEX NAME = F SNDXINDEX (NEW.LAST NAME)

Приложение 2. Решение сетевых проблем

Когда у вас возникают проблемы подключения клиента к серверу, этот набор тестов может помочь вам локализовать причину. Если все они ошибочны, не забывайте о возможности проверки сетевых кабелей: вставлены ли они в разъемы и чисты ли все контакты!

Следующий список содержит основные вещи, которые вы можете попытаться сделать.

Можете ли вы вообще соединиться с базой данных?

Если у вас запущен Суперсервер под Windows или Классический сервер в POSIX, проверьте, можете ли вы выполнить локальное соединение. (Суперсервер в POSIX и Классический сервер в Windows не поддерживают локальных соединений.)

1. Вызовите окно командной строки на машине сервера базы данных и запустите приложение типа isql или графический инструмент под Windows, такой как IB SQL или IBAccess.

2. Попытайтесь соединиться с базой данных без задания имени хоста- просто укажите путь.

POSIX (все в одной команде):

./isql /opt/firebird/examples/employee.fdb

-user SYSDBA -password yourpwd

Windows (все в одной команде):

isql ‘c:Program FilesFirebirdFirebird_1_5examplesemployee.fdb’

-user SYSDBA -password yourpwd

Если это работает, значит сервер запущен и путь к базе данных правильный. В противном случае проверьте пароль, а также находит ли ваше приложение правильную версию клиентской библиотеки.

Можете ли вы соединиться с базой данных в локально закольцованном варианте?

Для любой версии сервера (кроме Встроенного сервера под Windows) вы можете эмулировать клиентское соединение с сервером через интерфейс удаленного клиента, соединяясь в локально закольцованном режиме TCP/IP (loopback). Это рекомендованный режим для всех локальных соединений к полным серверам. Если сервисы TCP/IP сконфигурированы и запущены в системе, это должно работать, даже если не инсталлирована сетевая карта.

Вначале откройте файл hosts в текстовом редакторе и убедитесь, что он содержит запись, подобную следующей:

127.0.0.1 localhost # local loopback server

В Windows этот файл должен находиться в каталоге driversetc каталога %system%. В Windows 95/98 он, вероятно, находится в самом каталоге Windows. В POSIX он должен находиться в каталоге /etc.

Если такая запись отсутствует, добавьте ее, сохраните и закройте файл.

2. Попытайтесь соединиться с базой данных. POSIX:

./isql localhost:/opt/firebird/examples/employee.fdb -user SYSDBA -password yourpwd

Windows (все в одной команде):

isql ‘localhost:с:Program FilesFirebirdFirebird_1_5examplesemployee.fdb’

-user SYSDBA -password yourpwd

Если это работает, значит сервер запущен, TCP/IP работает, путь к базе данных правильный.

! ! !

ПРИМЕЧАНИЕ. Системы POSIX не исеользуют обозначение драйвера. При этом имя сервера, путь и имя файла чувствительны к регистру.

. ! .

Если локальное или локальное закольцованное соединение не проходит и вы уверены, что имя базы данных задано верно, следовательно есть какие-то ошибки в конфигурации сервера или сети.

Прослушивает ли сервер порт Firebird?

Сервис gds db (порт 3050) не будет отвечать, если серверный процесс не был запущен. См. табл. П2.1, где содержатся инструкции по запуску сервера.

Таблица П2.1. Запуск сервера

ОС	Инструкции
	Суперсервер
POSIX	Из командной строки войдите в каталог Firebird /bin и введите команду ibmgr -start
Windows: сервис	Используйте апплет Панель управления менеджера Firebird и щелкните мышью по Start, или в командной строке введите команду NET START FirebirdGuardianDefaultlnstance. В версии 1.0.x введите команду NET START FirebirdGuardian. Вы также можете попытаться запустить этот сервис из апплета Сервисы
Windows: приложение	Запустите Firebird Guardian или Firebird Server из меню Пуск
	Классический сервер
POSIX	Здесь не надо ничего делать. Если демон xinet (или inet на старых системах) запущен, он должен стартовать экземпляр fb_inet_server (ib_inet_server для версии 1,0.x), когда вы пытаетесь соединиться с базой данных
Windows: сервис	Перейдите в окно командной строки и введите NET START FirebirdGuardianDefaultlnstance. Вы также можете попытаться запустить этот сервис из апплета Сервисы
Windows: приложение	Запустите Firebird Server из меню Пуск. Замечание: не пытайтесь запускать Классический сервер из апплета Панель управления, не пытайтесь запускать приложение Guardian

Вы получили ошибку, хотя сервис выполняется?

Если клиент получает доступ к серверной машине и сервис gdsdb отвечает, но все еще не может соединиться с базой данных, вы можете увидеть ошибку отказа в соединении (connection rejected). Возможные варианты тестирования описаны в следующих разделах.

Находится ли база данных на физически локальном диске?

Файл базы данных не должен размещаться в файловой системе NFS, на назначенном или совместно используемом диске. Когда процесс ibserver обнаруживает такую ситуацию, он отказывает в соединении.

Для исправления этой ситуации переместите вашу базу данных в файловую систему на жесткий диск, который является физически локальным для сервера базы данных, и скорректируйте соответствующим образом вашу строку соединения.

Правильные ли имя пользователя и пароль?

Клиентское приложение должно использовать комбинацию имени пользователя и пароля, которая соответствует записи в базе данных безопасности на сервере. Эта база данных должна находиться в корневом каталоге инсталляции Firebird и должна быть перезаписываемой серверным процессом.

Имена пользователей и пароли применимы к серверу, а не к отдельной базе данных. Если вы перенесли базу данных с другого сервера, на котором были установлены роли и привилегии, то вы должны установить нужных пользователей на новом сервере.

Имеет ли владелец серверного процесса достаточно полномочий для открытия файлов?

Полномочия к файловой системе, включая права к каталогам, могут вызвать проблемы в POSIX. Полномочия к каталогам могут вызвать проблемы в разделах Windows MTFS.

Серверному процессу может понадобиться больше полномочий по созданию файлов (например, firebird.log или interbase.log) р корневом каталоге Firebird.

Попытки доступа к базам данных в областях файловой системы, которые не сконфигурированы для доступа к базе данных, могут вызвать проблемы в Firebird 1.5 и более поздних — см. параметр DatabaseAccess В файле firebird.conf.

! ! !

ПРИМЕЧАНИЕ. Если вы изменяли firebird.conf (версия 1.5+) или ibconfig/ isc_config (версия 1.0.x), вам будет нужно остановить сервер и заново запустить его, чтобы изменения вступили в силу.

. ! .

Может ли клиент найти хост?

Сообщение об ошибке «Unable to complete network request to host» (Невозможно завершить сетевой запрос к хосту) появляется, когда клиент Firebird не может установить сетевое соединение с серверной машиной. Существует несколько общих причин.

* Клиент не может найти хост в вашей сети. Ваш сервер Firebird должен выполняться в той сети, которую вы используете. Если имя хоста определяет хост, который недоступен по причине нарушений в сети, или хост просто не включен, запрос на соединение не может быть выполнен.

* Используются старые драйверы и/или клиентские библиотеки. Вы должны использовать драйверы (ODBC, BDE и т.д.), сертифицированные для работы с вашей версией сервера Firebird. Например, SQL Explorer, который поставляется вместе с некоторыми продуктами Borland, вероятно, не сможет работать с Firebird по причине использования слишком старой версии BDE.

* Приложение находит неверную клиентскую библиотеку. Все версии инструментов администратора пытаются загрузить библиотеку libgds.so (клиенты POSIX) или gds32.dll (клиенты Windows), отыскивая ее по системному пути по умолчанию. Клиент Firebird 1.5 имеет имя libfbclient .so или fbclient.dll и не располагается по системному пути по умолчанию. Изучите самые последние замечания в каталоге Firebird /doc и/или в корневом каталоге, чтобы найти решение.

* На месте имени сервера используется адрес IP. Если вы предоставляете адрес IP вместо имени хоста (имя сервера), то драйвер TCP/IP может оказаться неспособным разрешить его, или время попытки разрешения может оказаться слишком большим. Обычно это проблема Windows 95 и ранних версий NT 4. См. предыдущие замечания по созданию записи в файле hosts и использованию ее для всех клиентских машин.

* Адрес IP хоста является непостоянным. Системы, которые используют динамическую адресацию IP, могут изменять адрес IP хоста без выдачи предупреждающих сообщений. Похожие проблемы могут возникнуть, если хост-машина имеет более одной сетевой карты. Создайте записи в файле hosts на серверной и клиентской машинах, чтобы связать имя сервера с адресом IP. Firebird 1.5 также предоставляет возможность конфигурирования RemoteBindAddress для того, чтобы соединения могли находить правильный канал для сервера Firebird.

* Отсутствует или неправильная запись gdsjib в файле services. Клиенты Firebird будут отыскивать сервис gds db в порте по умолчанию 3050. Если вы изменили символ сервиса или номер порта в файле services, вероятно, у вас недостаточно информации в строке соединения, чтобы можно было выполнить это соединение. Вернитесь к разд. «Конфигурирование сервиса порта TCP/IP» главы 2, если вам нужно сделать подобную установку.

! ! !

ПРИМЕЧАНИЕ. Вероятны также проблемы с сервисом порта, если у вас сервер InterBase или другой сервер Firebird, запущенный на той же серверной машине. Хотя это можно делать в версии 1.5, однако требует аккуратности при конфигурировании и не может быть указано в момент установки Firebird.

. ! .

* Указанный сетевой протокол недоступен. Синтаксис строки соединения в Firebird определяет сетевой протокол, используемый клиентом для соединения с сервером. Если ваш сервер не поддерживает протокол, указанные в строке соединения, то попытка соединения будет неудачной с появлением ошибки сети. Например, строка соединения для именованных каналов Windows (NetBEUI) не будет работать, если сервер выполняется под Windows 95/98, ME или XP, в Linux или на другой платформе POSIX. Только TCP/IP будет работать на этих платформах.

! ! !

ПРИМЕЧАНИЕ. Клиентская библиотека Firebird не поддерживает сетевой протокол IPX/SPX. Соединение будет неудачным, если вы попытаетесь использовать IPX/SPX, задавая его в строке соединения с базой данных в виде server@volume:/path/database.fdb.

. ! .

* Вы пытаетесь соединиться с совместно используемым устройством. Невозможно соединиться с базой данных в Windows, NFS или SMB (Samba) с совместно используемым устройством. Должен использоваться абсолютный путь файловой системы, как он виден с хоста.

* Строка пути несовместима с существующим соединением. Суперсервер Firebird будет блокировать соединение, если полученная строка пути несовместима с путем, используемым в существующем соединении. В Firebird добавлен этот механизм для защиты баз данных от давно существующей ошибки в предыдущем коде InterBase, что приводило к разрушению сервера с базами данных Windows.

! ! !

ВНИМАНИЕ! Классический сервер не имеет такой защиты. Если у вас Классический сервер под Windows, убедитесь, что различные клиенты всегда соединяются с использованием такой же строки пути. Несовместимость появляется, т. к. Windows примет обозначение диска без последующей наклонной черты, а именно C:Databasesmydb.fdb вместо C:Databasesmydb.fdb. Это не является проблемой в POSIX, которая не имеет таких предпосылок к несовместимости.

. ! .

Нужно ли вам отключить автоматический набор номера для Интернета в Windows?

Операционные системы Microsoft Windows предоставляют по умолчанию сетевую возможность, удобную для пользователей, которые используют модем для подключения к Интернету — любой запрос TCP/IP, который появляется в сети, активизирует автоматическую программу набора номера. Это может стать проблемой для клиентских систем, использующих TCP/IP для доступа к серверу Firebird в локальной сети. Поскольку клиентские запросы применяют сервис TCP/IP, автоматически вызывается программа Windows набора номера, влияя на сетевые соединения от клиента к серверу.

Существует несколько способов отмены возможности автоматического набора номера. Для правильной работы необходимо сконфигурировать в вашей системе не более одного из этих методов.

Изменить порядок сетевых адаптеров

Возможно, на вашем компьютере есть драйвер соединения через модем и сетевая карта. В Windows NT и Windows 98 вы можете изменить порядок этих двух сетевых интерфейсов для того, чтобы сетевой адаптер использовался первым по отношению к сетевому драйверу модема.

Откройте Панель управления из меню Пуск и выберите Сетевые и Модемные соединения. Затем меню Дополнительно, и на вкладке Адаптеры и привязка в соответствующем месте поменяйте порядок адаптеров.

Изменение конфигурации Internet Explorer

Если у вас в качестве браузера установлен IE, откройте его апплет в Панели управления, и запретите автодозвон. Это находится в меню Соединения интернет- настроек браузера.

Здесь вы найдете несколько переключателей, один из которых нужен вам. Конкретное название переключателя меняется от версии к версии. Например, в английской версии Windows 2000 этот пункт называется Never dial a connection.

Запретить автодозвон через реестр

Для запрета автодозвона запустите Regedit и найдите ключ

HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet Settings

Найдите ключ EnabieAutoDiai в правой панели и выберите Изменить. Поменяйте значение с 1 на 0.

Запретить автодозвон RAS

На серверных платформах Windows вы можете запретить сервис RAS AutoDial. Для этого откройте Сервисы в Панели управления. В NT 4 сервисы доступны сразу из Панели управления. В последующих версиях Windows сервисы перенесены в Administrative Tools. Прокрутите сервисы до Remote Access Auto Connection Manager (или в NT 4 — Remote Access Dialup Manager) и выберите его. Измените опцию запуска на Manual (Вручную).

Чтобы остановить сервис прямо сейчас, нажмите кнопку Стоп. Для запуска- кнопку Старт.

Все еще есть проблемы?

Если проблема с подсоединением к серверу Firebird так и не исчезла, тогда имеет смысл обратиться к более квалифицированному специалисту по настройкам сети либо в один из форумов или списков рассылки. Обратитесь к приложению 12 за подробностями.

Приложение 3. Интерфейсы приложений

«Родным» интерфейсом Firebird по доступу к клиентской библиотеке является использование функции С и структур параметров, представляющих API. Заголовочный файл С ibase.h поставляется вместе с Firebird в каталоге /include. Этот заголовочный файл может быть применен при написании программ на языке С, которые используют клиентскую библиотеку, однако это полезный справочник и при разработке интерфейсов к библиотеке из других языков.

Драйверы JayBird JDBC

Драйверы JayBird JDBC для Firebird являются полностью совместимой с JDBC 2.0 абстракцией API Firebird, которая может быть использована в любых IDE, которые поддерживают драйверы JDBC, например, в Eclipse и Borland JBuilder.

Эти драйверы запускаются в Java 2 JRE 1.3.1 и Java 2 JRE 1 n.x и могут быть использованы со всеми популярными системами интерфейсов, поддерживающими JDBC 2.0, JDBC 2.0 Standard Extensions и JCA 1.0. Примеры включают JBoss 3.2.3, WebLogic 7.0, WebLogic8.1, ColdFusion MX, Hibernate (прозрачная постоянная система) и TJDO.

Последняя версия JayBird 1.5 была подготовлена к весне 2004 года.

Поддержка двухфазного подтверждения Firebird соответствует стандартному соглашению участия в распределенных транзакциях в Java, поддерживающих реализации JCA framework и XADataSource. JayBird соответствует модели JDBC «одна транзакция на соединение». Она не имеет нескольких транзакций на соединение, хотя они невидимо используются в JCA framework. JDBC не поддерживает события и массивы Firebird.

Лицензирование: JayBird является системой с открытыми кодами, свободно распространяемой или продаваемой на основании измененной лицензии BSD.

Загрузка: в вашем браузере войдите на http://sourceforge.net/projects/firebird/ и прокрутите страницу, пока не найдете строку, содержащую firebird-jca-jdbc-driver. Щелкните по Download справа, чтобы перейти к странице загрузки, где вы сможете выбрать желаемый комплект поставки из списка firebird-jca-jdbc-driver- например, FirebirdSQL-l.x.zip.

Поддержка: форум поддержки разработчиков и пользователей находится на http://groups.yahoo.com/group/firebird-java. Обширный, активно поддерживаемый список FAQ распространяется вместе с инсталляцией JayBird, а также доступен на различных сайтах сообщества, включая http://www.ibphoenix.com/main.nfs?a= ibphoenix&l=;FAQS;NAME=’ JayBird’.

ODBC

Драйвер Firebird ODBC/JDBC

Это свободно распространяемый, совместимый с JDBC драйвер ODBC с открытыми кодами для Firebird и InterBase 6.x, первоначально финансируемый IBPoenix и спонсорами сообщества, свободно реализуемый (во всех смыслах) под Initial Developer’s Public License. Версии библиотек драйвера доступны для Windows, Linux (unixODBC и iODBC), FreeDSB и Solaris. Самая последняя версия на момент выхода книги — 1.2.0060 совместима со спецификациями ODBC 3.0^[160]. Она поддерживает все версии и модели Firebird, включая Встроенный сервер под Windows версии 1.5.

Для соединения с базами данных Firebird приложения могут использовать множество дескрипторов DSN, каждый из которых реализован для различных клиентских версий. Если требуется, то в одном приложении могут быть параллельные соединения. Транзакция с двухфазным подтверждением может поддерживать до десяти соединений. Поддержка множества транзакций в одном соединении разрабатывалась, когда выходила эта книга. События Firebird не поддерживались.

Распространяются make-файлы для создания драйвера из исходных текстов С в gcc 2.96 Linux и более поздних, gcc freeBSD, gcc для Windows (MinGW), cc Solaris, BCC55 и MsVC6. Проекты IDE с make-файлами доступны для DEV-C++ 4.8 и более поздних, а также для MsVC6.

Драйвер ODBC Firebird — наиболее быстрый из доступных для Firebird и InterBase- хорошо работает с Open Office 1.1.0, Microsoft (Excel, VC6, VC7, VB6, VFP6, MsQry32, Access и т.д.) и с любыми компонентами, поддерживающими ADO. Он поддерживает зашифрованный пароль и прокручиваемые курсоры. Схемы интерфейса включают:

* универсальные компоненты (Excel, VFP6, VB6 и т.д.) и поддержку столбцов массивов, хранимые процедуры выбора и выполняемые хранимые процедуры с заменяемыми параметрами (CALL MYPROC ?), возможность {fn}, пакеты и полностью определенные имена столбцов;

* ADO OLEDB ODBC Manager

(odbc32.dll) OdbcJdbc;

* OLEDB(MSDADC.DLL) ODBC Manager OdbcJdbc;

* интерфейс пользовательских программ с ODBC Manager OdbcJdbc.

Драйвер поддерживает AutoQuotedidentifier для полной совместимости запросов с интерфейсами запросов Microsoft.

Загрузка совместно используемых библиотек:

http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_60_odbc.

Наиболее последние версии:

http://cvs.sourceforge.net/viewcvs.py/firebird/OdbcJdbc/BuiIds/. Самые последние состояния: http://www.praktik.km.ua (Владимир Цвигун). Форум поддержки и разработки: обратитесь к списку на https://lists.sourceforge.net/lists/listinfo/firebird-odbc-devel.

Другие драйверы ODBC^[161]

Драйвер XTG ODBC

Это свободный с открытыми кодами драйвер ODBC для Firebird/InterBase 6.x под Windows, соответствующий уровню ODBC 3 API CORE и распространяемый под лицензией LGPL. Версия 1.0.0 (бета 15) содержит ошибки, но ее можно использовать. В двоичном виде распространяется как полный инсталлятор Windows.

Загрузка двоичного кода: http://www.xtgsystems.com.

Исходные тексты: http://ofbodbc.sourceforge.net/drvinfo.html.

Драйвер Gemini ODBC

Это коммерческий драйвер ODBC для Windows и Linux, соответствующий спецификации Call Level Interface (CLI), разработанный в SQL Access Group, а затем адаптированный X/Open и ISO/IEC в качестве приложения к стандарту текущего языка SQL. В настоящий момент в версии 2.2 бета драйвер соответствует спецификации ODBC, описанной в ODBC Programmer’s Reference, версия 3.51. Более подробную информацию и загрузку пробной версии вы можете найти на http://www.ibdatabase.com^[162].

Драйвер Easysoft ODBC

Это коммерческий драйвер ODBC для InterBase под Windows и Linux. На некоторых платформах он поддерживает UNICODE. Более подробную информацию, загрузку пробной версии и описание форума поддержки можно найти на http:// www.easysoft.com/products/interbase.

Firebird .NET Provider

Открытые исходные тексты Firebird .NET Provider являются интерфейсом для данных, разработанным для работы приложений, созданных в окружениях Microsoft .NET. Самая поздняя стабильная версия (версия 1.5.2) поддерживает все версии Firebird, Классический сервер и Суперсервер для разработок в таких средах IDE, как:

* Microsoft Visual Studio 2002 и 2003;

* SharpDevelop (http://www.icsharpcode.net/OpenSource/SD);

* Borland С# Builder;

* Borland Delphi .NET (Delphi 8);

* MonoDevelop (http://www.monodevelop.com, в процессе тестирования).

Версия 1.2 на стадии бета 2 (когда эта книга выходила из печати), похоже, была создана летом 2004 года, поддерживает Firebird 1.5 Встроенный сервер для Windows и события Firebird.

Provider не поддерживает- и это ограничение архитектуры ADO .NET- нескольких транзакций в соединении или двухфазного подтверждения транзакций.

Поддерживаемые языки: С#, VB .NET, Microsoft Visual C++ .NET, Delphi .NET, ASP .NET и другие языки .NET. Известно, что он совместим со многими другими специализированными продуктами .NET, включая Gentle .NET (http://www.mertner.com /projects/gentle), NHibernate (http://nhibernate.sourceforge.net) и aspxDelphi.net PORTAL & STORE (http://www.aspxdelphi.net). Поддержка Firebird добавляется в следующей версии объектно-ориентированной оболочки LLBLGen Pro (http://www.llblgen.com/defaultgeneric.aspx).

Поддерживаемыми платформами являются Microsoft 1.0 и 1.1 (только Windows) и Mono (http://www.go-mono.com), проверенная под Windows и Linux. Планируется, что Firebird .NET Provider будет следовать курсом Mono, когда она станет доступной для других платформ (Solaris, FreeBSD, HP-UX и Mac OS X).

Загрузка: ссылка на загрузку текстов и документации:

http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_download_dotnet.

Форум поддержки и разработки: обратитесь к списку на http://lists.sourceforge.net/lists/listinfo/firebird-net-provider.

Для подписчиков доступен список на

http://sourceforge.net/mailarchive/forum.php?forum=firebird-net-provider.

IBPP для разработки C++

Это свободная с открытыми кодами библиотека классов интерфейса клиента C++ для сервера Firebird версий 1.0, 1.5 и следующих. Она свободна от любой специфики используемых для разработки инструментов. Разработана для обеспечения доступа к

Firebird из любого приложения C++, созданного с помощью не визуального (объекты CORBA/COM, другие библиотеки классов и функций, «традиционный» процедурный код) или визуального (RAD-средства) окружения. IBPP предоставляет «чистый» интерфейс DSQL к Firebird через простые в использовании классы C++ для администрирования базы данных и манипулирования данными.

Самой последней версией, когда выходила эта книга, была 2.3, поддерживающая все версии Firebird и модели клиент-сервер (Суперсервер, Классический сервер, Встроенный сервер) с полной поддержкой множества транзакций, транзакций с несколькими базами данных и событий Firebird.

IBPP поддерживает только чистый, стандартный код C++. Библиотека классов распространяется в виде исходных кодов, которые могут использоваться следующими компиляторами:

* Windows: Borland C++ Builder 6, свободно распространяемый компилятор командной строки Borland, MSVC 6, MSVC 7, Digital Mars C++, MingW и CygWin;

* POSIX: gcc 3.2 или выше;

* BCCP может успешно компилировать на многих других конфигурациях с небольшой настройкой в основном в make-файлах.

Лицензирование: Mozilla 1.1 и производные.

Загрузка и подробности поддержки: http://www.ibpp.org.

Форум поддержки: подпишитесь на http://lisb.sourceforge.net/lists/listinfo/ibpp- discuss.

Delphi, Kylix и Borland C++ Builder

IB Objects

Этот продукт объединяет две давно известные системы компонентов для Firebird и InterBase, которые позволяют разработчикам использовать инструменты Borland IDE (Delphi, Kylix, и Borland C++ Builder) для реализации всех возможностей Firebird. Одна система совместима с библиотеками Borland TDataset и другими компонентами сторонних разработчиков, которые наследуют архитектуру TDataset. Другая, известная как «родная IBO», основана на оригинальной иерархии классов, которые не связаны с архитектурой TDataset.

Текущей версией является 43xx, где xx представляет подрелизы и патчи релизов. Она поддерживает все версии Pascal для Delphi, начиная с 3, все версии Kylix, все версии C++ Builder 3 и выше и все модели клиент-сервер Firebird.

Компоненты, совместимые с TDataset, разработаны для эмуляции компонентов доступа к данным Borland VCL в той степени, что инструментов поиска и замены вполне достаточно для конвертирования устаревшего кода приложений BDE непосредственно в рабочую версию под IBO за несколько минут.

Родная система IBO включает собственный класс источников данных (data source) и множество управляющих элементов для управления данными. В отличие от компонентов, основанных на TDataset, IBO может быть использован с минимальным редактированием инструментами Borland. Некоторые известные инструменты обеспечивают поддержку этих компонентов.

Обе системы полностью поддерживают живые запросы, множество одновременных транзакций и транзакции к нескольким базам данных в одном приложении, события Firebird, однонаправленные и прокручиваемые курсоры и обратные вызовы. Родная система — которая совместима с невизуальными средствами на базе TDataset — поддерживает немедленное выполнение, кэширование событий DML в пределах приложения и расширенные операционные режимы, включая инкрементный поиск.

Поддержка: списки рассылки, электронная почта, онлайн FAQ, репозитарий кода сообщества, обновляемый сайт сообщества для подписки и обширная библиотека загружаемой документации. Обратитесь к списку на http://groups.yahoo.com /community/ibobjects. Web-сайт: http://www.ibobjects.com. Сайт для подписки: http://community.ibobjects.com.

Лицензирование: на доверии — полные исходные тексты (не открытые исходные тексты) поступают вместе с коммерческой подпиской или с некоммерческой благотворительной лицензией, открытыми исходными текстами проекта и для обучения.

Оценка: полнофункциональный набор IB Objects с частичными исходными кодами с неограниченной проверочной версией с сообщением при выполнении вне IDE всегда учитывает дату. Может быть загружено с http://www.ibobjects.com.

FIBPlus

Другой мощный набор компонентов для Delphi, Kylix и C++ Builder, FIBPlus был разработан с использованием в качестве основы FreeiBComponents как свободно распространяемые компоненты доступа к данным. В настоящее время FIBPlus развился до уровня полностью коммерческого продукта, который заявляет о максимальном упрощении и гибкости в использовании.

Основанные на архитектуре Borland TDataset, компоненты FIBPlus предоставляют полную совместимость со многими компонентами коммерческого характера и с открытыми кодами. Они предоставляют простой способ преобразования компонентов Borland InterBaseXpress.

Самая последняя версия FIBPlus 5.3^[163]. Проверочная версия доступна для всех поддерживаемых IDE: Delphi 5-7, C++ Builder 5-6 и Kylix 3. Более старые версии FIBPlus были все еще доступны для использования в более ранних продуктах Borland.

FIBPlus поддерживают все версии и модели клиент-сервер в Firebird. Эти компоненты совместимы со всеми инструментами и инструментами сторонних разработчиков, которые связаны с архитектурой TDataset. Некоторые продукты предоставляют пользовательскую поддержку FIBPlus.

Поддержка: компания предоставляет поддержку пользовательских групп на английском и русском языках, а также имеет систему «проблемных сообщений» для индивидуальной помощи. Адреса пользовательских групп:

* английский язык: news://news-devrace.com/FIBPlus.en;

* русский язык: news://news-devrace.com/fibplus.ru;

* сайт http://www.devrace.com для сведений о продукте и сообщениях об ошибках.

Другие

Для интерфейса с Firebird доступны некоторые другие наборы компонентов.

Компоненты UIB

Это набор небольших по объему компонентов доступа к данным с открытыми кодами и драйверы DBXpress для Firebird, InterBase и Yaffil^[164]. Это свободный набор под общей лицензией Mozilla. Данные компоненты работают не только с инструментами Borland (Delphi, Kylix, C++ Builder), но также со средой разработки Pascal с открытыми кодами Lazarus и FreePascal. Платформами являются Windows, Linux, и FreeBSD. Двоичные и исходные коды могут быть найдены на http://www.progdigy.com/UIB.

Драйверы Firebird DBXpress

Upscene Productions (http://www.upscene.com) создает драйверы DBXpress с низкой стоимостью для использования в Delphi, Kylix, C++ Builder. Часть от выручки продаж этих драйверов идет на будущие гранты разработчикам проекта Firebird.

Компоненты Zeos

Это компоненты с открытыми кодами для администрирования и разработки приложений баз данных, включая Firebird.

* Объекты базы данных Zeos: библиотека компонентов Delphi для быстрого доступа к Firebird (и другим СУБД).

* Управляющие элементы Zeos: библиотека визуальных компонентов Delphi для использования вместе с объектами базы данных Zeos.

* Библиотека классов Zeos: библиотека классов для разработки приложений C++ для платформ POSIX. Включает интерактивные утилиты графического интерфейса для выполнения запросов, администрирования, а также для работы с BLOB.

Лицензирование GPL, текущая версия 6.1.3. Подробности см. на http:// zeoslib.sourceforge.net.

Существует множество доступных пакетов компонентов. См. список на http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_dev_comps, также используйте для поиска Google.

InterBaseXpress

InterBaseXpress (IBX) содержит компоненты с открытыми исходными текстами для работы с базой данных и выполнения сервисных функций, которые поставляются вместе с некоторыми продуктами Borland, такими как Delphi, Kylix, C++ Builder. Исправленные от ошибок версии доступны в репозитории Code Central на http://community.borland.com. Не используйте версии, поставляемые с Delphi 5, 6 и с Kylix- это бета-версии с большим количеством ошибок, которые могут привести к разрушению базы данных. Более поздние версии с открытыми исходными кодами распространяются свободно и могут использоваться с Firebird 1.0.x. У некоторых пользователей возникли проблемы при употреблении компонентов соединения с базой данных в Firebird 1.5. IBX не является идеальным выбором для использования с Firebird в течение длительного времени, потому что его разработчик сообщил, что он не будет включать в них средства для распознавания отличий между Firebird и InterBase^[165].

IBOAdmin

Это набор оболочек компонентов для Firebird Service API (копирование-восстановление, статистика, безопасность и др.), основанных на кодах, первоначально распространявшихся как компоненты IBX Service. Они являются открытыми исходными кодами и требуют IB Objects. IBOAdmin свободно доступны на http:// www.mengoni.it.

PHP

PHP подтвердила, что является весьма подходящей платформой для разработки Web- клиентов баз данных Firebird при использовании расширений php-interbase. Сейчас стабильной версией PHP является 4.3.6. PHP 5.0 находится на поздней стадии бета- версии. В PHP 5.0 было добавлено множество новых функций для Firebird. Поищите «ibase» на http://www.php.net/ChangeLog-5.php#5.0.0RCl и последующих страницах.

PHP (http://www.php.net) и Apache Web Server (http://httpd.apache.org)- неразделимая пара для разработки приложений Firebird для Web. Платформами являются Windows (CGI, ISAPI) и Linux (CGI). Приверженцы Firebird PHP Windows рекомендуют использовать версию CGI на Windows Server 2003 и версию ISAPI на Windows 2000 для высокой производительности.

Расширения php-interbase прекрасно выполняются со всеми версиями Firebird на Apache 1 и Apache 2, но с одной проблемой реализации. PHP не обрабатывает 64-битовые целые (тип BIGINT) обычным образом, так что вам нужно будет преобразовывать значения BIGINT В строки. Вероятно, это не относится к PHP 5. Новая функция получения значения генератора Firebird, ibase_gen_id(), возвращает целое.

Как и другие общие интерфейсы доступа к данным, PHP использует модель «одна транзакция на одно соединение». При этом он не поддерживает множество транзакций. PHP следит за подтверждением незавершенных транзакций. Двухфазное подтверждение и события Firebird появились в PHP 5.

В Windows расширения php-interbase активизируются в файле PHP.ini после инсталляции. В Linux эти расширения должны создаваться из исходных кодов.

Доступны многие функции API, включая управление пользователями. Lutz Bruckner создал административный интерфейс (см. http://ibwebadmin.sf.net), который предоставляет наиболее полные возможности доступа.

Некоторые абстрактные средства доступны на страницах Firebird, включая классы ADODB (http://freshmeat.net/projects/adodb) и более компактный вариант ezSQL (http://php.justinvincent.com). PEAR-DB является другим абстрактным средством, которое формирует часть проекта PHP. Доступен также широкий выбор редакторов PHP. См. http://www.php-editors.com/review.

IDE: Eclipse (http://www. eclipse.org) и phpEclipse (http://www.phpeclipse.de/tiki- view_articles.php) предоставляют средства отладки и приятный набор инструментов редактирования. Eclipse выполняется как под Windows, так и под Linux, и включает встроенного клиента CVS, поддержку документации и возможность плагинов (http://www.eclipse-plugins.info/eclipse/plugins.jsp). Eclipse 3 был выпущен летом 2004 года.

Поддержка: разработчики Firebird PHP имеют небольшой, но активный список поддержки. Подпишитесь на http://www.yahoogroups.com/community/firebird-php.

* Для ADODB: http://phplens.com/lens/lensforum/topics.php?id=4.

* Для phpEclipse: http://www.phpeclipse.de/tiki-forums.php.

Ресурсы: лучшим началом работы с PHP является учебник (http:// www.php.net/docs.php). Сайт http://www.hotscripts.com/PHP/index.html рекомендуется как источник огромного количества скриптов и классов, которые может использовать Firebird.

Python

KlnterbasDB является пакетом расширения Python, который реализует совместимую с Python Database API 2.0 поддержку Firebird. В дополнение к минимальному набору возможностей Python Database API KlnterbasDB предоставляет полный API клиента Firebird.

После релиза версии 3.1 была объявлена самая новая доступная версия. Пакет распространяется свободно под разрешающей лицензией в стиле BSD, которую должны принять коммерческие и некоммерческие пользователи.

Поддержка, загрузка, документация онлайн и другая информация на

http://kinterbasdb.sourceforge.net/.

Perl

DBI — это модуль интерфейса с базой данных для Perl. Он определяет набор методов, переменных и соглашений, которые предоставляют согласованный интерфейс с базой данных, зависящий от фактически используемой базы данных.

DBD::InterBase являются открытыми кодами драйвера DBD для Firebird и InterBase. Располагаются на SourceForge (http://sourceforge.net/projects/dbi-interbase). Проект приглашает к участию разработчиков и пользователей.

Поддержка: присоединяйтесь к списку переписки на http://lists.sourceforge.net /mailman/listinfo/dbi-inter-base-devel.

Загрузка: отправляйтесь на http://www.cpan.org/moduIes/by-module/DBD для получения наиболее позднего стабильного релиза, посетите http://dbi.interbase.or.id за стабильным релизом и релизом разработки.

Приложение 4. Как выполнять ремонт базы данных

Вам придется потратить много сил для разрушения базы данных Firebird — система спроектирована так, чтобы выдержать тяжелые удары, которые ломают базы данных в других системах. Вы узнаете о том, что база данных разрушена, если вы не сможете с ней соединиться, не сможете выполнить ее резервное копирование или когда сообщение в протоколе firebird или от gbak -b сообщает вам, что существуют нарушения в базе, или появляются сообщения об ошибке контрольной суммы.

Если вы хотите понять, как могут появиться нарушения в вашей базе данных, вернитесь к разд. «Как разрушить базу данных Firebird» в конце главы 15^[166]

Восемь шагов восстановления

В этом приложении описаны шаги, которые вам нужно выполнить при использовании инструментов командной строки gfix или gbak, чтобы попытаться восстановить неповрежденные данные при некоторых видах разрушения. Однако имейте в виду, что существуют отдельные виды разрушения сервера, которые такая процедура не может исправить. См. в приложении 12 ресурсы, доступные для использования в этих случаях.

Для применения gfix и gbak в этой процедуре сделайте текущим каталог Firebird /bin на серверной машине.

Получение исключительного доступа

Первым делом, что нужно выполнить, когда появилось сообщение о разрушении, — это отключить всех пользователей от системы. Не позволяйте никому пытаться продолжить работу. Продолжение попыток использования базы данных может сделать восстанавливаемую базу данных невосстанавливаемой.

Проверка базы данных требует исключительного доступа к базе данных, иначе вы увидите следующее сообщение при попытке запустить gfix:

OBJECT database_name IS IN USE [Объект имя-базы-данных используется]

To же сообщение может появиться, если вы единственный пользователь, но имеете другую активную транзакцию. Например, утилита isql использует до трех параллельных транзакций. Остановив isql и другие инструменты администратора, вы можете выполнять работу.

Для получения исключительного доступа выполните останов базы данных, находясь пользователем SYSDBA или пользователем, являющимся владельцем базы данных. Подробности см. в главе 39. Например, следующая команда заблокирует все другие попытки соединения с базой данных и приведет к ее останову через две минуты:

gfix -sh -force 120 -user SYSDBA-password yourpword

Создание копии работающего файла

В этот момент gbak не может выполнить резервное копирование базы данных, содержащей разрушенные данные. Поскольку вы имеете исключительный доступ, выполните копирование средствами файловой системы (а не с помощью gbak) файла базы данных. В POSIX используйте команду ср, а в Windows команду сору или эквивалентное действие копировать/вставить в графическом интерфейсе. Убедитесь, что в этот момент нет пользователей, соединенных с базой данных, — даже вас!

Например, в Windows, находясь в каталоге базы данных, выполните:

copy damaged.fdb repaircopy.fdb

! ! !

ВНИМАНИЕ! Даже если вы можете восстановить исправленную базу данных, которая сообщала об ошибках контрольных сумм, может оказаться сложным определить объем потерянных данных. Если это важно, вы можете выбрать более раннюю копию, в которой вы сможете отыскать отсутствующие данные после проверки и починки разрушенных структур вашей текущей базы данных.

. ! .

Работайте с repaircopy.fdb.

Выполнение проверки

В первую очередь используются переключатели -v[alidate] и -f[ull] утилиты gfix для проверки структур записей и страниц. Процесс проверки сообщает о разрушенных структурах и освобождает неназначенные фрагменты записей или «осиротевших страниц» (т. е. страниц, которые выделены, но не назначены никаким структурам данных).

gfix -v -full {путь}repaircopy.fdb -user SYSDBA -password yourpword

Переключатель -n[o update] может быть использован вместе с -v для проверки и выдачи сообщений о разрушенных или не назначенных структурах без попыток их исправить:

gfix -v -n {путь}repaircopy.fdb -user SYSDBA -password yourpword

Если постоянно появляются ошибки контрольных сумм в процессе такого способа проверки, то используйте переключатель -i[gnore], чтобы проверка их игнорировала:

gfix -v -n -i {путь}repaircopy.fdb -user SYSDBA -password yourpword

Исправление разрушенных страниц

Если gfix сообщает о поврежденных данных, то следующий шаг — исправить (или починить) базу данных, убирая такие структуры.

Переключатель -m[end] отмечает разрушенные записи как недоступные, следовательно, они будут пропущены в процессе последующего резервного копирования. Включите переключатель -f[ull], чтобы запрос исправлял все разрушенные структуры, и переключатель -i[gnore], чтобы обходить ошибки контрольных сумм в процессе исправления.

gfix -mend -full -ignore {путь}repaircopy.fdb -user SYSDBA -password yourpword

или короче:

gfix -m -f -i {nyTb}repaircopy.fdb -user SYSDBA -password yourpword

Проверка после исправления -mend

После того как команда с переключателем -mend завершит свою работу, опять выполните

gfix -v -full {путь}repaircopy.fdb -user SYSDBA -password yourpword для проверки, остались ли еще разрушенные структуры.

Очистка и восстановление базы данных

Затем выполните полное резервное копирование и восстановление базы данных с использованием gbak, даже если все еще появляются сообщения об ошибках. Добавьте переключатель -v[erbose], чтобы видеть подробности. В своей простейшей форме команда резервного копирования может быть (все в одной команде):

gbak -b -v -i {путь}repaircopy.fdb {путь}repaircopy.fbk -user SYSDBA -password yourpword

Сложности в процессе резервного копирования

Проблемы сборки мусора могут привести к аварийному завершению gbak. Если такое произошло, добавьте переключатель -[g], чтобы сообщить, что не надо собирать мусор.

gbak -b -v -i -g {путь}repaircopy.fdb {путь}repaircopy.fbk -user SYSDBA -password yourpword

Если есть разрушения в версиях записей, связанных с зависшей транзакцией, вам может понадобиться добавить переключатель -limbo:

gbak -b -v -i -g -1 {путь}repaircopy.fdb (путь)repaircopy.fbk -user SYSDBA -password yourpword

Восстановление очищенной резервной копии в качестве новой базы данных

Теперь создайте новую базу данных из резервной копии с переключателем -v[erbose], чтобы наблюдать, что восстанавливается:

gbak -create -v {путь}repaircopy.fbk (путь)reborn.fdb -user SYSDBA -password yourpword

Проверка восстановленной базы данных

Убедитесь, что восстановление базы данных разрешило проблемы, выполнив проверку восстановленной базы данных с использованием переключателя -n[o update]:

gfix -v -full {путь}reborn.fdb -user SYSDBA -password yourpword

Если существуют проблемы с восстановлением, вам может быть придется рассмотреть возможности новых попыток с использованием других переключателей gbak для уменьшения источников этих проблем, например:

* переключатель -i[nactive] уменьшит проблемы с разрушенными индексами за счет восстановления без активизации каких-либо индексов. Потом вы сможете активизировать индексы вручную по одному за раз, пока не будет найден проблемный индекс;

* переключатель -o[ne_at_a_time] будет восстанавливать и подтверждать каждую таблицу одну за другой, позволяя вам восстанавливать хорошие таблицы и пропуская проблемные.

Как поступать, если проблемы остались

Если предыдущие шаги не дают результатов, но вы все еще в состоянии соединяться с разрушенной базой данных, можно переслать структуры таблиц и данных из разрушенной базы данных в новую, используя инструмент qli (Query Language Interpreter). Этот инструмент находится в вашем каталоге Firebird /bin, а руководство по его синтаксису в формате Adobe PDF может быть загружено с http:// www.ibphoenix.com/downloads/qIi_syntax.pdf. qli является старым инструментом, однако он все еще работает, когда вам понадобится. Поищите в Интернете, как выполнить перекачку данных между базами данных с использованием qli.

В приложении 5 есть ссылки на инструменты починки базы данных, которые, возможно, помогут вам в восстановлении разрушенной базы данных.

Существуют компании, которые предоставляют сервис по восстановлению и починке сильно разрушенных баз данных Firebird и InterBase — хотя во время написания этой книги автор услышала о базе данных Firebird, которая была разрушена так, что для ее исправления требовался чародей!

Приложение 5. Инструменты администрирования

Одной из «приятных проблем» новичка в использовании Firebird является выбор инструментов. Почему? Потому что сообщество Firebird имеет огромное количество прекрасных инструментов, как коммерческих, так и свободно распространяемых. Чуть ли не все коммерческие продавцы предоставляют свободные пробные версии, так что вашей самой большой проблемой является выбор такого инструмента, который лучше всего подходил бы вам.

Графические инструменты администратора

Следующий список является лишь выборкой некоторых наиболее популярных элементов. Полный список см. на http://www.ibphoenix.com/main.nfs?a=ibphoenix &page=ibp_admin_tooIs.

Database Workbench

Database Workbench может соединяться с любым сервером Firebird на любой платформе. Он имеет полный визуальный интерфейс, браузер метаданных и зависимостей, средства отладки хранимых процедур, инструменты миграции данных, импорт/экспорт, редактор BLOB, управление пользователями и полномочиями, генератор тестовых данных, поиск метаданных, репозиторий фрагментов кода, средства печати метаданных, автоматическую генерацию триггеров для автоинкрементных ключей, не чувствительный к регистру поиск столбцов и многое другое.

Окружение: Windows.

Другая инфорлюция: коммерческий программный продукт от Upscene Productions. Свободная пробная версия доступна на http://www.upscene.com.

IBExpert

Этот нагруженный возможностями инструмент администрирования имеет средства гиперссылок и возможность хранения историй во всех редакторах. Он также имеет SQL Monitor, визуальный конструктор запросов, режимы фильтрации выхода для запросов, фоновое выполнение запросов, прямой импорт данных CSV, завершение кода, отладку, трассировку и советы по PSQL, настраиваемые шаблоны клавиатуры, редактирование и отображение BLOB (включая рисунки и двоичные коды), редакторы пользователей и полномочий, режим автоматического предоставления полномочий для создания новых объектов, моделирование сущностей, средство сравнения баз данных с созданием обновляющих скриптов, формирование планов и выполнения, инструменты для скриптов, включая скрипты по выводу данных BLOB, предварительно определенные и определенные пользователем отчеты схемы, мастер резервного копирования, средства диагностики соединения, поддержку нескольких языков и многое другое.

Окружение: Windows.

Другая информация: коммерческий^[167] программный продукт от H-К Software GmbH. Доступно Free Personal Edition (Свободное персональное издание). Также доступна версия для образовательных целей.

BlazeTop

BlazeTop имеет необычный модульный интерфейс для основных инструментов, что помогает решить проблему «перегрузки возможностей» — вы инсталлируете только модули, которые вы хотите использовать. Он включает интеллектуальный текстовый редактор, который создает шаблоны операторов, а также включает средства управления схемой, SQL Monitor, интерактивное редактирование данных, инспектор объектов в стиле Delphi для объектов базы данных и явное управление транзакциями. Он может одновременно запускать множество сессий баз данных.

Окружение: Windows.

Другая информация: коммерческий программный продукт от Devrace. Свободная пробная версия доступна на http://www.devrace.com/en/blazetop.

IB Access

Этот кроссплатформенный менеджер баз данных предоставляет графический интерфейс для реализации всех задач, которые Firebird не доверяет выполнять инструментам командной строки, делая его совместимым с Классическими серверами так же, как и с Суперсерверами. Он предоставляет оперативную справку, конфигурацию рабочего стола для пользователя или для сервера, а также возможность запуска нескольких экземпляров для выполнения долгих задач в фоновом режиме. В нем вы можете отслеживать операторы SQL в процессе их выполнения; просматривать и управлять объектами данных, полномочиями и полями BLOB; выполнять запросы с заменяемыми параметрами; выполнять скрипты шаг за шагом.

Окружение: Linux, Windows.

Другая информация: открытые исходные тексты (Mozila Public License), свободный программный продукт от Тони Мартира (Toni Martir). Доступны исходные тексты. См. http://www.ibaccess.org,

IBAdmin

Это онлайновый и офлайновый менеджер баз данных, предоставляющий визуальное проектирование баз данных — инструменты CASE, — отладчик SQL, анализатор кода, завершение кода, сравнение базы данных с необязательным скриптом обновления, макровозможности, инструменты выполнения скриптов, контроль версий для модулей PSQL, инструмент исследования базы данных, средства для добавления ваших собственных инструментов (предоставляется пример).

Окружение: Windows, Linux (усеченный вариант).

Другая информация: коммерческий программный продукт от Sqlly Development. Продукт доступен в профессиональной, стандартной и «живой» версиях. Загрузка пробной версии осуществляется с http://www.sqlly.com.

IB_SQL

Компактная утилита с множеством инструментов, является заменой старой программы Borland W1SQL с «живым» браузером данных и метаданных, выделением метаданных, перекачкой данных, экспортом, управлением пользователями, отслеживанием SQL и профилированием, использованием скриптов, интерактивными запросами с заменяемыми параметрами и отображением плана. Содержит средства, которые автоматически сохраняют подробности подключения к различным базам данных и инструмент Query Forms для сохранения указанных запросов для будущего использования.

IB SQL может быть загружен в виде двоичных кодов или настраиваемых и компилируемых в Delphi исходных текстов, поставляемых в пробном комплекте IB Objects (IB SQL.dpr в корневом каталоге). Компилированный таким образом IB SQL покажет модальный экран при старте вне IDE Delphi или C++ Builder.

Окружение: Windows.

Другая информация: свободный программный продукт. Исходные тексты являются субъектом лицензии Trustware. См. http://www.ibobjects.com, там содержатся исходные тексты IB SQL и самый последний пробный комплект IBO.

IBOConsole

Это заново спроектированная версия утилиты IBOConsole, которая поставляется с пакетом открытых текстов InterBase 6 с улучшениями, исправленными ошибками и поддержкой для разработки Firebird. Она реализует Services API (управление пользователями, резервное копирование и др.), а также возможности интерактивных запросов и скриптов. Уровнем абстракции API является IB Objects, а не Borland InterBaseXpress.

Окружение: Windows.

Другая информация: свободный с открытыми кодами (InterBase Public License) программный продукт от Lorenzo Mengoni. Доступны исходные коды. Загрузка и подробности на http://www.men-goni.it.

Инструменты резервного копирования

DBak

DBak является альтернативной утилитой резервного копирования базы данных, которая не использует gbak или Services API. Она копирует базу данных в новую, используя скрипты DDL и перемещение данных. Ее абстрактным уровнем API является IB Objects.

Поскольку DBak оперирует с одной транзакцией SNAPSHOT, она получает надежный мгновенный снимок состояния базы данных на момент старта копирования. Вместе с копированием и восстановлением DBak также может выполнять прямое пересоздание, генерируя рабочую копию базы данных без каких-либо промежуточных стадий.

Процесс работы может настраиваться различными способами, делая работу особенно полезной для помощи в управляемом восстановлении при некоторых вариантах разрушения и при автоматическом обновлении схемы. Поставка включает графический пользовательский интерфейс и консольную версию для пакетных и запланированных операций.

Окружение: Windows.

Другая информация: выполняемые файлы и файлы помощи от Telesis Computing Pty Ltd являются свободно распространяемыми. Полная исходная версия доступна по низкой цене под лицензией Trustware. Информация и загрузка могут быть найдены на http://www.telesiscomputing.com.au/dbk.htm. Обратите внимание, что это не gbak, важно прочесть документацию и понимать разницу.

gbak BackupRunner

Это элегантная, небольшая по объему графическая программа пользователя для утилиты Firebird gbak. Она не использует Services API, а предоставляет вместо этого флаги для установки переключателей gbak. По требованию утилита формирует информационные сообщения прямо в текстовое окно, которое может быть сохранено в качестве протокола. Она требует присутствия gbak.exe.

Окружение: Windows.

Другая информация: свободные двоичные коды от Marco Wobben. Информация и загрузка могут быть найдены на http://www.bcp-software.nl/backuprunner.

Time То Backup

Это набор программ для Firebird, с помощью которого устанавливают копирование по расписанию в виде сервиса Windows или демона Linux на одной или более хост- машинах. Содержит конфигурацию графического интерфейса и управляемый интерфейс для локального или удаленного использования. Конфигурация интерфейса только для командной строки доступна также для Linux.

Окружение: Windows, Linux.

Другая информация: программное обеспечение с открытыми исходными кодами на основании лицензии LGPL от Sqlly Development. Инструменты свободно распространяются с полными исходными кодами на Object Pascal. Информацию и загрузку см. на http://www.sqlly.com/timetobackup.asp.

Разное

Инструменты починки базы данных IBSurgeon

Компания IBSurgeon распространяет множество инструментов для диагностики и починки разрушенных баз данных, а также для восстановления поврежденных резервных копий БД. Ее инструменты диагностики IBFirstAid Diagnostician и IBSurgeon Viewer могут быть свободно загружены. Инструменты, выполняющие фактическую починку, должны быть куплены. Некоторые виды ошибок невозможно восстановить автоматическими инструментами, но компания утверждает, что разрушенные базы данных могут быть переведены в работоспособное состояние в 70% случаев.

Прочесть об этих инструментах и получить советы, как поступать, когда у вас есть разрушенная база данных, которую не может починить gfix, можно на http://www.ib- aid.com.

Анализатор статистики IBAnalyst

IBAnalyst- это инструмент для анализа статистики баз данных InterBase или Firebird, поиска проблем в производительности базы данных, сопровождении, или работы приложений.

IBAnalyst решает две важные задачи:

* визуализирует статистику базы данных и сообщает об актуальных или возможных проблемах;

* предлагает проверенные советы по улучшению производительности базы данных, на основе автоматического анализа ее статистики.

Рекомендуется для регулярного изучения состояния базы данных.

Бесплатен для России и стран СНГ: www.ibase.ru/download/ibanalyst_r.zip.

Interbase DataPump

Interbase DataPump позволяет довольно просто и с полным контролем над процессом перекачивать данные и выполнять их миграцию из любого источника ADO/BDE/ODBC (такого как dBase, Paradox, Access, MSSQL, Sybase, Oracle, DB2, InterBase и т.д.), а также из родных баз данных Firebird в новую базу данных Firebird. Он определяет такие важные детали, как порядок создания объектов с учетом зависимостей.

Инструмент может генерировать полный скрипт SQL для создания базы данных Firebird на основе метаданных из источника ADO/BDE/ODBC, предоставляя при этом полный список типов данных, индексов, ключей, автоинкрементных полей, ссылочной целостности и проверочных ограничений. Он может создавать требуемые генераторы и триггеры для автоинкрементных полей и набор правильных начальных значений.

Окружение: Windows.

Другая информация: программное обеспечение от Clever Components. Подробную информацию и загрузку можно найти на http://www.clevercomponents.com /products/datapump/ibdatapump.asp.

Advanced Data Generator для Firebird

Advanced Data Generator является инструментом для генерации тестовых данных, которые имитируют реальные данные. Существует возможность генерации случайных адресов, поддержка ссылочной целостности, поддержка BLOB. Содержит большую библиотеку данных по компаниям, персоналу, географическим названиям; может также использовать ваши данные. Можно организовать очередь множества проектов.

Окружение для генерации данных: Windows.

Другая информация: коммерческий программный продукт от Upscene Productions. Информацию и загрузку пробной версии можно найти на http://www.upscene.com.

Менеджеры полномочий

Попробуйте использовать эти инструменты для упрощения управления пользователями, ролями и полномочиями SQL:

* Grant Manager от Eadfost на http://www.eadsoft.com/english/products/ grantmanager. Пробная версия этого продукта под Windows доступна в качестве 30-дневной утилиты в виде отдельной программы или как Delphi SDK;

* Grant Master от Studio Plus Inc. Подробную информацию об этой программе под Windows и загрузку 30-дневной пробной версии можно найти на http:// www.studioplus.com.ua/GrantMaster/GrantMaster.phtml.

Где посмотреть информацию о других инструментах

«Основной список» инструментов от сторонних разработчиков можно найти в разделе Downloads Cohtributed на http://www.ibphoenix.com^[168].

Разработчики инструментов также посылают объявления в почтовый список на firebird-tools@yahoogroups.com. Вы можете подписаться на этот список, перейдя на http://groups.yahoo.com/group/firebird-tools или просто просматривая зеркальный сайт (egroups.ib-tools) на news://news.atkin.com.

Не рассматривайте поиск в Google как способ найти инструменты для конкретной задачи. Обычно ввод слов «firebird», «interbase» и ключевого слова, идентифицирующего задачу, сгенерирует хорошие ссылки.

Приложение 6. Пример базы данных

Пример базы данных инсталлируется вместе в Firebird в каталог /examples в корневом каталоге Firebird. В Firebird 1.0 это база данных диалекта 1, ее имя employee.gdb. В версии 1.5 она имеет диалект 3 и имя employee.fdb. Структурно это та же самая база данных.

Эта база данных была создана много лет тому назад, возможно, для тренировок персонала поддержки. Она не является образцом хорошего моделирования. Более того, она не имеет набора символов по умолчанию. Однако она содержит данные, с которыми можно экспериментировать.

База данных поставляется в виде резервной копии (employee.gbk и employee.fbk соответственно), следовательно, не имеет значения, как вы будете перемешивать в ней данные — вы всегда сможете восстановить нормальную копию.

Создание базы данных Employee с помощью скриптов

После выполнения инсталляции Firebird база данных Employee будет создана и будет сделана ее резервная копия из скриптов. Скрипты empddl.sql (который создает метаданные) и empdll.sql (который заполняет базу данных) доступны в области Downloads на http://www.apress.com с некоторыми изменениями.

* Добавлен набор символов по умолчанию, который установлен в ISO8859_1, со- — вместимый с данными на английском языке в empdml.sql.

* Был добавлен оператор SET SQL DIALECT 3, поскольку без него некоторые инструменты создавали базу данных с диалектом 1, а отдельные эксперименты, которые проводились с родным диалектом SQL Firebird, завершались с ошибкой или давали неожиданный результат.

* Был добавлен полный путь в оператор CREATE DATABASE, чтобы показать, как реально создаются базы данных. Эта строка создает базу данных на сервере POSIX в каталоге с именем /data/examples. Закомментированная строка будет создавать базу данных в каталоге C:dataexamples. Комментируйте, убирайте комментарий и изменяйте код в соответствии с вашими потребностями.

* Кавычки в пути у CREATE DATABASE были заменены на апострофы.

* Скрипт empdml.sql начинается с оператора SET NAMES ISO8859_I для обеспечения того, что дальнейшие текстовые данные будут сохраняться в правильном наборе символов.

Несмотря на эти небольшие изменения, база данных Employee остается в значительной степени тем, чем она всегда и была, — примером того, как не надо проектировать базы данных! Новый пример базы данных для Firebird сейчас создается. Он должен быть готов к концу 2004 года на http://www.apress.com и на других сайтах сообщества Firebird. В конце концов этот пример будет поставляться в комплекте Firebird.

Приложение 7. Ограничения Firebird

Большинство фактических ограничений Firebird практически шире того, что нужно в программах. Например, вы можете определить до 32 767^[169] столбцов в таблице, однако зачем вы будете это делать? В табл. 7.1 представлены теоретические и практические ограничения, применимые к Firebird 1.0.x и 1.5. Некоторые из этих ограничений будут изменены в сторону улучшения в следующих версиях, так что просматривайте заметки по релизу, чтобы отследить изменения.

Таблица П7.1. Ограничения Firebird 1.0.x и 1.5

Объект	Элемент	Firebird 1.0.x	Firebird 1.5	Замечания
Идентификаторы	Почти все объекты	31 символ	31 символ	Нельзя использовать символы вне диапазона US ASCII (ASCIIZ)
	Имена ограничений	27 символов	27 символов
Даты	Самые ранние и самые поздние даты			января 100 г.
	Самая поздняя			31 декабря 9999 г. Замечание: считается, что сервер может аварийно завершаться, если системная дата на сервере установлена больше, чем 2039^[170].
Сервер	Максимальное количество подключенных клиентов^[171]	024 (TCP/IP)	024 (TCP/IP)	Теоретическое ограничение меньше для Windows с именованными каналами (NetBEUI) — сервер, скорее всего, зависнет при более чем 930 одновременных соединениях. Практически нормальным будет не более 150 одновременных подключений клиентов Суперсервера при обычных интерактивных приложениях для сервера с низкими спецификациями. Для Классического сервера это количество может быть меньше по причине того, что каждый клиент использует больше ресурсов
	Максимальное количество баз данных, открытых в одной транзакции			Количество баз данных, открытых при запуске транзакции с помощью isc_start_multiple(), ограничивается только доступными системными ресурсами. Транзакция, запущенная с помощью isc start transaction(), ограничивает количество одновременно подключенных баз данных 16
База данных	Количество таблиц	32 767	32 767
	Максимальный размер	7 Тбайт	7 Тбайт	Приблизительное теоретическое ограничение. Не известна база данных Firebird с таким количеством записей, чтобы ее размер превышал 7 Тбайт
	Максимальный размер файла			Зависит от файловой системы. В FAT32 и ext2 2 Гбайт. Более старая NTFS и ext3 обычно дают 4 Гбайт. Многие 64-битовые файловые системы не устанавливают ограничений на размер файла с совместным доступом
	Максимальное количество файлов в базе данных			Теоретически 216 (65 536) включая файлы оперативной копии (shadow). Порог будет ниже, если операционная система накладывает ограничения на количество файлов, которое может быть одновременно открыто в одном процессе. Некоторые позволяют увеличить эту границу
	Максимальный размер страницы	16 386 байт	16 386 байт	Другими размерами являются 1024, 2048, 4096 (по умолчанию) и 8192 байт
	Максимальное количество буферов кэша	65 536 страниц	65 536 страниц	Практическое ограничение зависит от доступного объема RAM. Общий размер (страницы * размер страницы для Суперсервера, страницы * размер страницы * количество одновременных пользователей для Классического сервера) никогда не долженпревышать половины доступной памяти RAM. Рассматривайте в качестве практического ограничения 10 000 страниц и увеличивайте или уменьшайте, отходя от этого количества, в соответствии с требованиями производительности
Таблицы	Максимальное количество версий для структуры таблицы	255	255	Firebird сохраняет не более 255 форматов для каждой таблицы. Версия формата увеличивается на 1 каждый раз, когда выполняется изменение метаданных. Когда таблица достигает ограничения, вся база данных становится недоступной — нужно сделать ее резервную копию и выполнить восстановление
	Максимальный размер строки	64 Кбайт	64 Кбайт	Подсчитывается в байтах. Столбцы массивов и BLOB каждый занимает 8 байт для хранения идентификатора; VARCHAR — длина в байтах + 2; CHAR — длина в байтах; SMALLINT — 2; INTEGER, FLOAT, DATE и TIME — 4; BIDINT, DOUBLE PRECISION и TIMESTAMP — 8; NUMERIC и DECIMAL — 4 или 8 в зависимости от точности. Системные таблицы имеют ограничение на размер страницы 128 Кбайт
	Максимальное количество строк^[172]	2(^32^) строки	2(^32^) строки	Больше или меньше. Строки под- считываются с помощью 32-битового беззнакового целого для таблиц и 32-битового для индекса. Таблица с длинной строкой — имеющая много полей или с очень длинными полями — может хранить меньше строк, чем таблица с очень короткими строками. Все строки — включая удаленные — попадают в это число; поля BLOB, хранимые на страницах данных таблицы, также входят в это число
	Максимальное количество столбцов			Зависит от используемых типов данных (см. Максимальный размер строки)
	Максимальное количество индексов на таблицу	64	256
	Максимальный размер внешнего файла			4 Гбайт в Windows NTSF, 2 Гбайт в Windows FAT32, Linux ext2, ext3 и Solaris
Индексы	Максимальный размер^[173]	252 байт	252 байт	Этот теоретический максимум применяется к индексу из одного столбца, где набор символов является однобайтовым и использует порядок сортировки по умолчанию (двоичный). Подсчитываются байты, а не символы. Практический максимум уменьшается для составных индексов, многобайтовых наборов символов и сложных порядков сортировки. Например, индекс для одного столбца, использующего 3-байтовые символы UNICODE_FSS, может иметь максимум (253/3) = 84 символа. Некоторые последовательности сортировки для ISO8859 используют до 4 байт на символ только для атрибутов сортировки
	Максимальное количество сегментов	16	16
Запросы	Максимальное количество соединяемых таблиц	256	256	Теоретическое ограничение
	Максимальное количество вложенных подзапросов			Теоретически предела нет, но большая вложенность подзапросов ухудшает производительность. Производительность и потребление ресурсов определяется практическими лимитами, конкретно для каждого запроса
	Максимальный размер столбца, составляющего поля ORDER BY	32 Кбайт	32 Кбайт
Модули PSQL	Максимальный размер BLR	48 Кбайт	48 Кбайт	Текст хранимых процедур и триггеров компилируется в байт-код (BLR), который более компактен, чем исходный текст. Если вы все- таки обнаружили ограничение, попробуйте разбить вашу монументальную процедуру на несколько частей, вызываемых из главной процедуры
	Максимальное количество событий в процедуре или триггере	Нет ограничения	Нет ограничения	Практический лимит совпадает с ограничением на размер BLR
	Количество рекурсивных вызовов			750 на Windows, 1000 на платформах POSIX
BLOB	Максимальный размер BLOB			Максимум зависит от размера страницы. Для страницы 2 Кбайт максимальный размер — 512 Мбайт. Для 4 Кбайт — 4 Гбайт. Для страниц размера 4 и 8 Кбайт — 32 и 256 Гбайт соответственно
	Максимальный размер сегмента			BLOB хранятся посегментно, теоретический максимальный размер которого не более 64 Кбайт. В DSQL нет возможности указать размер сегмента, поскольку его устанавливает клиентская программа или библиотека-компонент, как правило, игнорируя размер сегмента, указанный в определении BLOB

Приложение 8. Наборы символов и порядков сортировки

В табл. П8.1 содержатся наборы символов и порядки сортировки, которые существовали на момент создания Firebird 1.5.0. Некоторые из указанных элементов недоступны в более ранних версиях Firebird. Если вы инсталлировали более позднюю версию, и набор символов или порядок сортировки, нужные вам, здесь не указаны, обратитесь к заметкам по релизу вашей версии и любой другой версии после 1.5, чтобы узнать были ли они добавлены.

Таблица П8.1. Наборы символов и порядок сортировки для Firebird 1.5.0

ID	Название	Байтов на символ	Порядок сортировки	Язык	Алиас
2	ASCII	1	ASCII	Английский	ASCII7 USASCII
56	BIG_5	2	BIG_5	Китайский, Вьетнамский, Корейский	BIG5, DOS_950, WIN_950
50	CYRL	1	CYRL, DB_RUS, PDOX_CYRL	Русский, Русский dBase, Русский Paradox
10	DOS437	1	DOS437, DB_DEU437, DB_ESP437, DB_FIN437, DB_FRA437, DB_ITA437, DB_NLD437, DB_SVE437, DB_UK437	Английский (США), Немецкий dBase, Испанский dBase, Финский dBase, Французский dBase, Итальянский dBase, Голландский dBase, Шведский dBase, Английский (Великобритания) dBase,	DOS_437
			DB_US437	Английский (США) dBase,
			PDOX_ASCII	Кодовая страница Paradox- ASCII,
			PDOX_SWEDFIN	Paradox Шведская / Финская кодовые страницы,
			PDOX_NTL	Paradox международный английский кодовая страница
9	DOS737	1	DOS737	Греческий	DOS_737
15	DOS775	1	DOS775	Страны Балтии	DOS_775
11	DOS850	1	DOS850, DB_DEU850, DB_ESP850, DB_FRA850, DB_FRC850, DB_ITA850, DB_NLD850, DB_PTB850, DB_SVE850, DB_UK850, DB_US850	Латинский I (нет символа Евро), Немецкий, Испанский, Французский, Французский — Канада, Итальянский, Голландский, Португальский — Бразилия, Шведский, Английский — Великобритания, Английский — США	DOS_85C>
45	DOS852	1	DOS852, DB_CSY, DB_PLK, DB_SLO, PDOX_CSY, PDOX_HUN, PDOX_PLK, PDOX_SLO	Латинский II, Чешский dBase, Польский dBase, Словацкий dBase, Чешский Paradox, Венгерский Paradox, Польский Paradox, Словацкий Paradox	DOS_852
46	DOS857	1	DOS857 DB_TRK	Турецкий, Турецкий dBase	DOS_857
16	DOS858	1	DOS858	Латинский I с символом Евро	DOS_858
13	DOS86Q	1	DOS86O DB PTG860	Португальский, Португальский dBase	1
47	DOS861	1	DOS861 PDOX_SL	Исландский, Исландский Paradox	DOS_861
17	DOS862	1	DOS862	Иврит	DOS_862
14	DOS863	1	DOS863 DB_FRC863	Французский — Канада, Французский dBase — Канада	DOS_863
18	DOS864	1	DOS864	Арабский	DOS_864
12	DOS865	1	DOS865 DB_DAN865 DB_NOR865 PDOX_NORDAN4	Скандинавские, Датский dBase, Норвежский dBase, Paradox Норвегия и Дания	DOS_865
48	DOS866	1	DOS866	Русский	DOS_866
49	DOS869	1	DOS869	Современный греческий	DOS_869
6	EUCJ_0208	2	EUCJ_0208	Японские EUC	EUCJ
57	GB_2312	2	GB_2312	Упрощенный китайский (Гонконг, Корея)	DOS_936, GB2312, WIN_936
21	ISO8859_1	1	ISO8859_1, DA_DA, DE_DE, DU_NL, EN_UK, EN_US, ES_ES, FI_FI, FR_CA, FR_FR, IS_IS, IT_IT NO_NO, PT_PT, sv_sv	Латинский I, Датский, Немецкий, Голландский, Английский, Великобритания, Английский, США, Испанский, Финский, Французский, Канада, Французский, Исландский, Итальянский, Норвежский, Португальский, Шведский	ANSI, ISO88591, LATIN 1
22	ISO8859_2	1	ISO8859_2, CS_CZ ISO_HUN	Латинский 2 — Центральная Европа (хорватский, чешский, венгерский, польский, румынский, сербский, словацкий, словенский), Чешский, Венгерский	ISO-8859-2, ISO88592, LATIN2
23	ISO8859_3	1	ISO8859_3	Латинский 3 — Южная Европа (мальтийский, эсперанто)	ISO-8859-3, ISO88593, LATIN3
34	ISO8859_4	1	ISO8859_4	Латинский 4 — Северная Европа (эстонский, латышский, литовский, гренландский, саамский)	ISO-8859-4, ISO88594, LATIN4
35	ISO8859_5	1	ISO8859_5	Кириллица (русский)	ISO-8859-5, ISO88595
36	ISO8859_6	1	ISO8859_6	Арабский	ISO-8859-6, ISO88596
37	ISO8859_7	1	ISO8859_7	Греческий	ISO-8859-7, ISO88597
38	ISO8859_8	1	ISO8859_8	Иврит	ISO-8859-8, ISO88598
39	ISO8859_9	1	ISO8859_9	Латинский 5	ISO-8859-9, ISO88599, LATIN5
40	ISO8859_1 3	1	ISO8859_13	Латинский 7 — Балтика	ISO-8859- 13, ISO885913, LATIN 7
44	KSC_5601	2	KSC_5601 KSC_DICTIONARY	Корейский, Корейский — словарный порядок сортировки	DOS_949, KSC5601, WIN_949
19	NEXT	1	NEXT NXT_DEU NXT_FRA NXT_ITA NXT_US	Кодирование NeXTSTEP, Немецкий, Французский, Итальянский, Английский, США
0	NONE	1	NONE	Нейтральная кодовая страница. Перевод в верхний регистр ограничен кодами ASCII 97-122
1	OCTETS	1	OCTETS	Двоичный символ	BINARY
5	SJIS_0208	2	SJIS_0208	Японский	SJIS
3	UNICODE FSS	3	UNICODE_FSS	UNICODE	SQL_TEXT, UTF-8, UTF8, UTF_FSS
51	WIN1250	1	WIN1250, PXW_CSY, PXW_HUN, PXW_HUNDC, PXW_PLK PXW_SLO	ANSI, Центральная Европа, Чешский, Венгерский, Венгерский, словарная сортировка, Польский, Словацкий	WIN.1250
52	WIN1251	1	WIN1251 WIN1251_UA PXW_CYRL	ANSI кириллица, Украинский, Paradox кириллица (русский)	WIN_1251
53	WIN1252	1	WIN1252 PXW_NTL PXW_INTL850 PXW_NORDAN4 PXW_SPAN PXW_SWE D FIN	ANSI — Латинский I, Английский интернациональный, Paradox многоязыковой Латинский I, Норвежский и датский, Paradox испанский, Шведский и финский	WIN_1252
54	WIN1253	1	WIN1253 PXW_GREEK	ANSI греческий, Paradox греческий	WIN_1253
55	WIN1254	1	WIN1254 PXW_TURK	ANSI турецкий, Paradox турецкий	WIN_1254
58	WIN1255	1	WIN1255	ANSI иврит	WIN_1255
59	WIN1256	1	WIN1256	ANSI арабский	WIN_1256
60	WIN1257	1	WIN1257	ANSI стран Балтии	WIN_1257

Приложение 9. Системные таблицы и просмотры

Когда вы создаете базу данных, Firebird начинает с создания своих собственных таблиц, в которых он сохраняет метаданные всех объектов базы данных — не только определенных вами объектов, но также и своих собственных внутренних объектов. Эти таблицы называются системными таблицами. Просматривая определения метаданных для системных таблиц, вы найдете листинги DDL для множества просмотров для системных таблиц, которые могут оказаться вам полезными.

Системные таблицы

Описания в этом разделе помогут вам в проектировании запросов для понимания и администрирования ваших баз данных. Для изменения метаданных существуют операторы DDL. Вообще не рекомендуется использовать операторы SQL для изменения таблиц метаданных. Риск разрушения базы данных при выполнении таких действий весьма высок.

В таблицах применяются следующие аббревиатуры:

* 1DX-индексировано;

* UQ — уникальное.

Где существуют составные индексы, приведены цифры для указания последовательности индексных сегментов.

RDB$CHARACTER_SETS хранит ключи для наборов символов, доступных базе данных.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$CHARACTER_SET_NAME	CHAR(31)	Y	Y	Имя набора символов, известного в Firebird
RDB$FORM_OF_USE	CHAR(31)			Не используется
RDB$NUMBER_OF_CHARACTERS	INTEGER			Количество символов в наборе (не используется для доступных наборов символов)
RDB $ DEFAULT COLLATE_NAME	CHAR(31)			Название двоичной последовательности сортировки для этого набора символов. Это название всегда совпадает с названием набора символов
RDB $ CHARACT ER_SET_I D1	SMALLINT	Y	Y	Уникальный идентификатор для этого набора символов, если он используется
RDB$SYSTEM_FIAG	SMALLINT			Будет 1, если набор символов был определен в системе при создании базы данных; 0 для набора символов, определенного пользователем
RDB$DESCRIPTION	BLOB TEXT			Для хранения документации
RDB$FUNCTION_NAME .	CHAR(31)			Не используется, но может стать доступным для наборов символов, определенных пользователем, доступ к которым осуществляется через внешнюю функцию
RDB$BYTES_PER_CHARACTER	SMALLINT			Размер символов в наборе, указанный в байтах. Например, UNICODE_FSS использует 3 байта на символ

KDB$CHECK_CONSTKAXNTS содержит перекрестные ссылки имен и триггеров для ограничений CHECK и NOT NULL.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$CONSTRAINT_NAME	CHAR(31)	Y		Имя ограничения
RDB$TRIGGER_NAME	CHAR(31)			Для ограничения CHECK это имя триггера, который поддерживает данное ограничение. Для ограничения NOT NULL это имя столбца, к которому применяется ограничение — имя таблицы может быть найдено через имя ограничения

RDB$COLLATIONS хранит определения последовательностей сортировки.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$COLLATION_NAME	VARCHAR(31)	Y	Y	Имя последовательности сортировки
RDB $ COLLATI ON_I D	SMALLINT	Y(1)	Y(1)	Вместе с идентификатором набора символов является уникальным идентификатором последовательности сортировки
RDB$CHARACTER_SET_IB	SMALLINT	Y(2)	Y(2)	Вместе с идентификатором последовательности сортировки является уникальным идентификатором
RDB$COLLATI ON_ATTRIBOTES	CHAR(31)			Не используется
RDB$SYSTEM_FLAG	SMALLINT			Определенное пользователем = 0; определенное в системе = 1 или выше
RDB$DESCRIPTION	BLOB TEXT			Для хранения документации
RDB$FONCTION_NAME	CHAR(31)			В настоящий момент не используется

RDB$DATABASE является файлом из одной записи, содержащей основную информацию о базе данных.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$DESCRIPTION	BLOB TEXT			Текст комментария, включенный в оператор CREATE DATABASE/CREATE SCHEMA, предназначен для того, чтобы быть записанным здесь. Этого не происходит. Однако вы можете сюда добавить любое количество текста с целью документирования. Он сохранится после резервного копирования и восстановления
RDB$RELATION_ID	SMALLINT			Число, которое каждый раз увеличивается на единицу, когда к базе данных добавляется новая таблица или просмотр
RDB$SECORITY_CLASS	CHAR(31)			Может ссылаться на класс безопасности, определенный в RDB$SECORITY_CLASSES, для обращения к общим для базы данных ограничениям доступа
RDB$CHARACTER_SET_NAME	CHAR(31)			Набор символов по умолчанию для базы данных. NULL — набор символов NONE

RDB$DEPENDENCIES хранит зависимости между объектами базы данных.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$DEPENDENT_NAME	CHAR(31)	Y		Имена просмотра, процедуры, триггера или вычисляемого столбца, на которые происходит ссылка в этой записи
RDB $ DEPENDED_ON_NAME	CHAR(31)	Y		Таблица, на которую ссылается просмотр, процедура, триггер или вычисляемый столбец
RDB$FIELD NAME	VARCHAR (31)			Имя столбца в таблице зависимости, на который ссылается просмотр, процедура, триггер или вычисляемый столбец
RDB$DEPENDENT_TYPE	SMALLINT			Идентифицирует тип объекта (просмотр, процедура, триггер, вычисляемый столбец). Номер приходит из таблицы RDB$TYPES — объекты нумеруются в соответствии RDB$FIELD_NAME = ‘RDB$OBJECT_TYPE’
RDB$DEPENDED_ON_TYPE	SMALLINT			Идентифицирует тип зависимого объекта (тот же принцип, что и в RDB$DEPENDENT_TYPE)

RDB$EXCEPTIONS хранит пользовательские исключения.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB $ EXC EPTION _NAME	CHAR(31)	Y	Y	Имя пользовательского исключения
RDB$EXCEPTION_NUMBER	INTEGER	Y	Y	Назначенный системой уникальный номер исключения
RDB$MESSAGE	VARCHAR(78)			Текст пользовательского сообщения
RDB$DESCRIPTION	BLOB TEXT			Может быть использовано для документации
RDB$SYSTEM_FLAG	SMALLINT			Определенное пользователем = 0; определенное системой = 1 или выше

KDB$FIELD_DIMENSIONS сохраняет информацию о размерностях столбцов массивов.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$FIELD_NAME	CHAR (31)	Y		Имя столбца массива. Должно содержаться в RDB$FIELD_NAME В таблице RDB$FIELDS
RDB$DIMENSION	SMALLINT			Определяет одну размерность столбца массива. Первым значением является 0
RDB$LOWER_BOUND	INTEGER			Нижняя граница этой размерности
RDB$UPPER_BOOND	INTEGER			Верхняя граница этой размерности

RDB$FIELDS хранит определения доменов и имен столбцов для таблиц и просмотров. Каждая строка для столбца, не являющегося доменом, соответствует строке в RDB$RELATION_FIELDS. В действительности каждый экземпляр в RDB$FIELDS является доменом. Например, вы можете выполнить следующее:

CREATE TABLE ATABLE (

EXAMPLE VARCHAR(10) CHARACTER SET ISO8859_1) ; COMMIT;

SELECT RDB$FIELD_SOURCE FROM RDB$RELATION_FIELDS WHERE RDB$RELATION_NAME = ‘ATABLE’ AND RDB$FIELD_NAME = ‘EXAMPLE’; RDB$FIELD_SOURCE

SQL$99 /* */

ALTER TABLE ATABLE

ADD EXAMPLE2 SQL$99; COMMIT;

Добавлен новый столбец, имеющий те же атрибуты, что и исходный.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$FIELD NAME	CHAR(31)	Y	Y	Для доменов это имя домена. Для столбцов таблиц и просмотров это внутреннее, уникальное для базы данных имя поля, связанное С RDB$FIELD_SOURCE В RDB$RELATION_FIELDS. Замечание: Firebird создает домен в этой таблице для каждого определения столбца, которое не наследуется от определенного пользователем домена
RDB$QUERY_NAME	CHAR (31)			He используется в Firebird
RDB$VALIDATION_BLR ,	BLOB BLR			He используется в Firebird
RDB $ VALIDATION_S OURCE	BLOB TEXT			He используется в Firebird
RDB$COMPUTED_BLR	BLOB BLR			Двоичное представление выражения SQL, которое использует Firebird для вычисления при обращении к столбцу COMPUTED BY
RDB$COMPUTED_SOURCE	BLOB TEXT			Оригинальный исходный текст выражения, которое определяет столбец COMPUTED BY
RDB$DEFAULT_VALUE	BLOB BLR			Правило по умолчанию для значения по умолчанию в двоичном виде
RDB $ DE FAULT_SOURCE	BLOB TEXT			То же; в исходном виде
RDB$FIELD_LENGTH	SMALLINT			Длина столбца в байтах, FLOAT, DATE, TIME, INTEGER занимают 4 байта. DOUBLE PRECISION, BIGINT, TIMESTAMP и идентификатор BLOB — 8 байт
RDB$FIELD_SCALE	SMALLINT			Отрицательное число задает масштаб для столбцов DECIMAL и NUMERIC
RDB$FIELD_TYPE	SMALLINT			Числовой код типа данных для столбца: 7 = SMALLINT, 8 = INTEGER, 12 = DATE, 13 = TIME, 14 = CHAR, 16 = BIGINT, 27 = DOUBLE PRECISION, 35 = TIMESTAMP, 37 = VARCHAR, 261 = BLOB. Коды для DECIMAL и NUMERIC имеют тот же размер, что и их целые типы, используемые для их хранения
RDB$FIELD_SUB_TYPE	SMALLINT			Подтип BLOB, а именно: 0 = не типизовано, 1 = текст, 2 = BLR (Binary Language Representation, представление в двоичном коде), 3 = ACL (Access Control List, список управления доступом), 5 = закодированные метаданные таблицы, 6 = описание транзакций между таблицами, которые не завершились нормально
RDB$MISSING_VALUE	BLOB BLR			Не используется в Firebird
RDB$MISSING_SOURCE	BLOB TEXT			Не используется в Firebird
RDB$DESCRIPTION	BLOB TEXT			Доступно для использования в документации
RDB$SYSTEM_FLAG	SMALLINT			= системная таблица, все другое — таблица, определенная пользователем
RDB$QUERY_HEADER	BLOB TEXT			Не используется в Firebird
RDB$SEGMENT LENGTH	SMALLINT			Для столбцов BLOB требуемая длина буферов BLOB. Не требуется в Firebird
RDB$EDIT_STRING	VARCHAR(125)			Не используется в Firebird
RDB$EXTERNAL_LENGTH	SMALLINT			Длина поля, как она представляется для внешней таблицы. Всегда 0 для обычных таблиц
RDB$EXTERNAL_SCALE	SMALLINT			Коэффициент масштаба для целого поля во внешней таблице; задается степенью 10, на которую умножается целое
RDB$EXTERNAL_TYPE	SMALLINT			Тип данных поля, как он представляется во внешней таблице. Типы данных те же самые, что и в обычных таблицах, только включают еще 40 = завершаемый нулем текст (CSTRING)
RDB$DIMENSIONS	SMALLINT			Задает количество размерностей массива, если столбец был определен как тип массива. Для столбцов, не являющихся массивами, всегда 0
RDB$NULL_FLAG	SMALLINT			Указывает, может ли столбец принимать пустое значение (NOLL) или не может (1)
RDB$CHARACTER_LENGTH	SMALLINT			Длина столбца CHAR или VARCHAR в символах (не в байтах)
RDB$COLLATION_ID	SMALLINT			Номер идентификатора последовательности сортировки (если задана) для символьного столбца или домена
RDB$CHARACTER_SET_ID	SMALLINT			Номер идентификатора набора символов для символьного столбца, столбца BLOB или домена. Связан со столбцом RDB$CHARACTER_SET_ID В RDB$CHARACTER_SETS
RDB$FIELD_PRECISION	SMALLINT			Указывает количество цифр после десятичной точки, доступное для типа данных этого столбца

RDB$FILES хранит множество деталей о вторичных файлах базы данных и о файлах оперативной копии.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$FILE_NAME	VARCHAR(253)			Имя вторичного файла (тома) базы данных в многотомной базе данных или файла оперативной копии
RDB$FILE_SEQUENCE	SMALLINT			Порядковый номер вторичного файла в последовательности томов базы данных или номер в наборе оперативных копий
RDB$FILE_START	INTEGER			Начальный номер страницы
RDB$FILE_LENGTH	INTEGER			Длина файла в страницах базы данных
RDB$FILE_FLAGS	SMALLINT			Для внутреннего использования
RDB$SHADOW_NUMBER	SMALLINT			Номер набора оперативных копий. Требуется для идентификации файла, как члена набора оперативных копий. Если значение NULL или 0, Firebird предполагает, что файл является вторичным файлом в томах базы данных

RDB$FILTERS запоминает и хранит следы информации о фильтрах BLOB.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$FUNCTION NAME	CHAR(31)			Уникальное имя фильтра BLOB
RDB$DESCRIPTION	BLOB TEXT			Написанная пользователем документация о фильтре BLOB и используемых двух подтипах
RDB$MODULE_NAME	VARCHAR (253)			Имя динамической библиотеки / совместно используемого объекта, где расположен код фильтра BLOB
RDB$ENTRYPOINT	CHAR (31)			Точка входа в библиотеке фильтров для этого фильтра BLOB
RDB$INPUT_SUB_TYPE	SMALLINT	Y(1)	Y(1)	Подтип BLOB для преобразуемых данных
RDB$OUTPUT_SUB_TYPE	SMALLINT	Y(2)	Y(2)	Подтип BLOB, в который преобразуются входные данные
RDB$SYSTEM_FLAG	SMALLINT			Внешне определенный фильтр (т. е. определенный пользователем = 0, внутренне определенный = 1 или более)

RDB$FORMATS хранит информацию об изменениях метаданных, выполненных для таблиц. Каждый раз, когда таблица или просмотр изменяются, таблица получает новый номер формата. Цель этого — позволить приложениям получать доступ к измененной таблице без необходимости их перекомпилировать. Когда номер формата любой таблицы достигает 255, вся база данных становится недоступной для запросов. Тогда нужно выполнить резервное копирование, восстановить эту копию и продолжить работу с заново созданной базой данных.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$RELATION ID	SMALLINT	Y(1)	Y(1)	Идентификатор таблицы или просмотра в RDB$RELATIONS
RDB$FORMAT	SMALLINT	Y(2)	Y(2)	Идентификатор формата таблицы. Форматов может быть до 255, как и строк для любой конкретной таблицы
RDB$DESCRIPTOR	BLOB FORMAT			Отображение в виде BLOB столбцов и атрибутов данных на момент, когда была создана запись формата

RDB$FUNCTXON_ARGUMENTS хранит атрибуты аргументов (параметров) внешних функций.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$FUNCT ION_NAME	CHAR(31)	Y		Уникальное имя внешней функции, соответствующее имени функции В RDB$FUNCTIONS
RDB $ ARGUMENT?? OS ITI ON	SMALLINT			Позиция аргумента в списке аргументов: 1 = первый, 2 = второй и т.д.
RDB$MECHANISM	SMALLINT			Передается ли аргумент по значению (0), по ссылке (1), через дескриптор (2) или через дескриптор BLOB (3)
RDB$FIELD_TYPE	SMALLINT			Числовой код, задающий тип данных для столбца: 7 = SMALLINT, 8 = INTEGER, 12 = DATE, 13 = TIME, 14 = CHAR, 16 = BIGINT, 27 = DOUBLE PRECISION, 35 = TIMESTAMP, 37 = VARCHAR, 40 = CSTRING (строка, завершаемая нулем), 261 = BLOB
RDB$FIELD_SCALE	SMALLINT			Масштаб для целого числа или аргумента с фиксированной точкой
RDB$FIELD_LENGTH	SMALLINT			Длина аргумента в байтах. Длины несимвольных типов см. RDB$FIELDS.RDB$FIELD_LENGTH
RDB$FIELD SOB TYPE	SMALLINT			Для аргумента BLOB задает подтип BLOB
RDB$CHARACTER_SET_ID	SMALLINT			Идентификатор набора символов для символьного аргумента, если применим
RDB$FIELD_PRECISION	SMALLINT			Количество цифр точности, допустимой для типа данных аргумента
RDB$CHARACTER_LENGTH	SMALLINT			Длина аргумента CHAR или VARCHAR в символах (не в байтах)

RDB$FUNCTIQNS хранит информацию о внешних функциях.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$FUNCTION_NAME	CHAR(31)	Y	Y	Уникальное имя внешней функции
RDB$FUNCTION TYPE	SMALLINT			В настоящий момент не используется
RDB$QUERY_NAME	CHAR(31)			Имелось в виду, что будет альтернативным именем функции для использования в запросах isql. На самом деле не работает
RDB$DESCRIPTION	BLOB TEXT			Может использоваться для документации
RDB$MODULE NAME	VARCHAR(253)			Имя динамической библиотеки / совместно используемого объекта, где расположен код функции
RDB$ENTRYPOINT	CHAR(31)			Имя точки входа в библиотеке, где можно найти эту функцию
RDB$RETURN_ARGUMENT	SMALLINT			Номер позиции возвращаемого аргумента в списке параметров, соответствующем входным аргументам
RDB$SYSTEM_FLAG	SMALLINT			Определенная пользователем функция = 1, определенная системой = 0

RDB $ GENERATORS хранит имена и идентификаторы генераторов.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$GENERATOR_NAME	CHAR(31)	Y	Y	Уникальное имя генератора
RDB$GENERATOR_ID	SMALLINT			Назначаемый системой уникальный идентификатор для генератора
RDB$SYSTEM_FLAG	SMALLINT			0 = определенный пользователем, 1 или выше = определенный системой. Firebird внутренне использует множество генераторов

RDB$INDEX_SEGMENTS хранит сегменты и позиции составных индексов.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$INDEX_NAME	CHAR(31)	Y		Имя индекса. Должно быть согласованным с соответствующей главной записью в RDB$INDICES
RDB$FIELD_NAME	CHAR(31)			Имя ключевого столбца в индексе. Соответствует RDB$FIELD_NAME имени столбца базы данных в RDB$RELATION_FIELDS
RDB$FIELD_POSITION	SMALLINT			Последовательная позиция столбца в индексе (упорядоченность слева направо)

RDB$INDICES хранит определения всех индексов.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$INDEX NAME	CHAR(31)	Y	Y	Уникальное имя индекса
RDB$RELATION_NAME	CHAR(31)	Y		Имя таблицы, к которой применяется индекс. Соответствует RDB$RELATION_NAME в записи RDB$RELATIONS
RDB$INDEX_ID	SMALLINT			Внутренний идентификатор индекса. Запись данных в этот столбец из приложения приведет к поломке индекса
RDB$ONIQUE FLAG	SMALLINT			Указывает, является ли индекс уникальным (1 = уникальный, 0 = не уникальный)
RDB$DESCRIPTION	BLOB TEXT			Доступно для документирования
RDB$SEGMENT_COUNT	SMALLINT			Количество сегментов (столбцов) в индексе
RDB$INDEX_INACTIVE	SMALLINT			Указывает, является ли в настоящий момент индекс неактивным (1 = неактивный, 0 = активный)
RDB$INPEX_TYPE	SMALLINT			В настоящий момент не используется. Видимо, нужен для различения обычных индексов и индексов выражений, когда такая возможность будет реализована
RDB$FOREIGN_KEY	VARCHAR(31)	Y		Имя ассоциированного ограничения внешнего ключа, если существует
RDB$SYSTEM_FLAG	SMALLINT			Указывает, является ли индекс определенным системой (1 или выше) или пользователем (0)
RDB$EXPRESSION_BLR	BLOB BLR			Представление выражения на языке двоичного представления (BLR). Будет использовано для вычисления во время выполнения, когда будут реализованы индексы выражений
RDB$EXPRESSION_SOURCE	BLOB TEXT			Исходный текст выражения. Будет использовано, когда будут реализованы индексы выражений
RDB$STATISTICS	DOUBLE PRECISION			Хранит самую последнюю селективность индекса, вычисленную при запуске или с помощью оператора SET STSTISTICS

RDB$LOG_FILES является устаревшей системной таблицей. RDB $ PAGES хранит информацию о страницах базы данных.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$PAGE_NUMBER	INTEGER			Уникальный номер страницы базы данных, которая была выделена физически
RDB$RELATION ID	SMALLINT			Идентификатор таблицы, чьи данные хранятся на этой странице
RDB$PAGE_SEQOENCE	INTEGER			Последовательный номер этой страницы по отношению к другим страницам, выделенным для этой таблицы
RDB$PAGE_TYPE	SMALLINT			Идентифицирует тип данных, хранящихся на этой странице (данные таблицы, индекса и т.д.)

RDB$PROCEDURE_PARAMETERS хранит параметры хранимых процедур.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$PARAMETER NAME	CHAR (31)	Y(2)	Y(2)	Имя параметра
RDB$PROCEDURE_NAME	CHAR(31)	Y(1)	Y(1)	Имя процедуры
RDB$PARAMETER_NUMBER	SMALLINT			Последовательный номер параметра
RDB$PARAMETER_TYPE	SMALLINT			Указывает, является ли параметр входным (0) или выходным (1)
RDB$FIELD_SOURCE	CHAR(31)			Сгенерированное системой уникальное имя столбца
RDB$DESCRIPTION	BLOB TEXT			Доступно для документирования
RDB$SYSTEM_FLAG	SMALLINT			Указывает, является ли параметр определенным системой (1 и выше) или пользователем (0)

RDB$PROCEDURES содержит описания хранимых процедур.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$PROCEDURE_NAME	CHAR(31)	Y	Y	Имя процедуры
RDB$PROCEDURE ID	SMALLINT	Y		Определенный системой уникальный идентификатор процедуры
RDB$PROCEDURE INPUTS	SMALLINT			Указывает, существуют входные параметры (1) или нет (0)
RDB$PROCEDURE_OUTPUTS	SMALLINT			Указывает, существуют выходные параметры (1) или нет (0)
RDB$DESCRIPTION	BLOB TEXT			Доступно для документирования
RDB$PROCEDURE_SOURCE	BLOB TEXT			Исходный код процедуры
RDB$PROCEDURE_BLR	BLOB BLR			Двоичное представление (BLR) кода процедуры
RDB$SECURITY CLASS	CHAR(31)			Может указывать на класс безопасности, определенный в RDB$SECURITY_CLASSES, для применения ограничений управления доступом
RDB $ OWNER_NAME	VARCHAR(31)			Имя пользователя — владельца процедуры
RDB$RUNTIME	BLOB SUMMARY			Описание метаданных процедуры. Внутреннее использование для оптимизации
RDB$SYSTEM_FLAG	SMALLINT			Определена пользователем (0) или системой (1 или выше)

RDB$REF_CCNSTRAXNTS хранит действия для ссылочных ограничений.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$CONSTRAINT_NAME	CHAR (31)	Y	Y	Имя ссылочного ограничения
RDB$CONST_NAME_HQ	CHAR(31)			Имя ограничения первичного или уникального ключа, на которое ссылается предложение REFERENCES в этом ограничении
RDB$MATCH_OPTION	CHAR(7)			Текущим значением является NULL во всех случаях. Резервируется для будущего использования
RDB$UPDATE_RULE	CHAR(11)			Действия по ссылочной целостности, применимые к данному внешнему ключу, когда изменяется первичный ключ: NO ACTION \| CASCADE \| SET NULL \| SET DEFAULT
RDB$DELETE_RULE	CHAR(11)			Действия по ссылочной целостности, применимые к данному внешнему ключу, когда удаляется первичный ключ. Правила те же, что указаны в столбце RDB$UPDATE RULE

RDB$RELATION_CONSTRAINTS хранит информацию об ограничениях целостности на уровне таблицы.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$CONSTRAINT_NAME	CHAR(31)	Y	Y	Имя ограничения на уровне таблицы
RDB$CONSTRAINT_TYPE	CHAR(11)	Y(2)		Первичный ключ / уникальный ключ / внешний ключ / ограничение CHECK / NOT NULL
RDB$RELATION NAME	CHAR(31)	Y(1)		Имя таблицы, к которой применяется это ограничение
RDB$DEFERRABLE	CHAR(3)			В настоящий момент во всех случаях N0. Резервируется для будущей реализации отложенных ограничений
RDB$INITIALLY_DEFERRED	CHAR(3)			То же
RDB$INDEX_NAME	CHAR(31)	Y		Имя индекса, который поддерживает это ограничение (применимо, если ограничением является PRIMARY KEY, UNIQUE или FOREIGN KEY)

RDB$REIATION_FIELDS хранит определения столбцов.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$FIELD_NAME	CHAR(31)	Y(1)	Y(1)	Имя столбца, уникальное в таблице или просмотре
RDB$RELAT \| ON_NAME	CHAR (31)	Y(2)	Y(2)	Имя таблицы или просмотра
		Y		(Другой индекс)
RDB$FIELD_SOURCE	CHAR (31)	Y		Имя, сгенерированное системой (SQL&nnn) для этого столбца, коррелирующееся с RDB$FIELDS. Если столбец основан на домене, то два связанных столбца RDB$FIELD_SOURCE хранят имя домена
RDB$QUERY_NAME	CHAR(31)	Y		В настоящий момент не используется
RDB$BASE_FIELD	CHAR(31)			Только для запроса. Имя столбца из базовой таблицы. Базовая таблица идентифицируется по внутреннему идентификатору в столбце RDB$VIEW_CONTEXT
RDB$EDIT_STRING	VARCHAR(125)			Не используется в Firebird
RDB$FIELD_POSITLON	SMALLINT			Позиция столбца в таблице или просмотре по отношению к другим столбцам. Заметьте, что для таблиц вы можете изменить это с использованием ALTER TABLE ALTER COLUMN POSITION n, где n — новая позиция поля
RDB$QUERY HEADER	BLOB TEXT			He используется в Firebird
RDB$UPDATE_FLAG	SMALLINT			Не используется в Firebird
RDB$FIELD_ID	SMALLINT			Временный номер идентификатора, используемый внутренне. Он изменяется после копирования / восстановления, следовательно, на него не следует полагаться в запросах приложений. Не изменяйте его
RDB$VI EW_CONTEXT	SMALLINT			Для столбца просмотра внутренний идентификатор базовой таблицы, откуда приходит это поле. Не изменяйте этот столбец
RDB$DESCRIPTION	BLOB TEXT			Может документировать этот столбец
RDB$DEFAULT VALUE	BLOB BLR			Представление в двоичном языке предложения DEFAULT, если оно присутствует
RDB$SYSTEM_FLAG	SMALLINT			Определено пользователем (0) или системой (1 или выше)
RDB$SECURITY_CLASS	CHAR(31)			Может ссылаться на класс безопасности, определенный в RDB$SECURITY_CLASSES для применения ограничений управления доступом для всех пользователей этого столбца
RDB$COMPLEX_NAME	CHAR(31)			Резервируется для будущих реализаций
RDB$NULL_FLAG	SMALLINT			Указывает, допускает ли столбец значения NULL (пусто) или не допускает
RDB$DEFAULT_SOURCE	BLOB TEXT			Начальный исходный текст из предложения DEFAULT, если присутствует
RDB$COLLATION_ID	SMALLINT			Идентификатор последовательности сортировки для столбца не по умолчанию

RDB$RELATIONS хранит информацию заголовка таблиц и просмотров.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$VIEW_BLR	BLOB BLR			Представление в двоичном языке спецификации запроса для просмотра; NULL для таблиц
RDB$VIEW_SOURCE	BLOB TEXT			Спецификация запроса для просмотра
RDB$DESCRIPTION	BLOB TEXT			Можно использовать для документирования
RDB$RELATION_ID	SMALLINT	Y		Внутренний идентификатор таблицы. Не изменяйте этот столбец
RDB$SYSTEM_FLAG	SMALLINT			Указывает, создана ли таблица пользователем (0) или системой (1 или выше). Не изменяйте этот флаг для таблиц, определенных пользователем или системой
RDB$DBKEY LENGTH	SMALLINT			Для просмотров общая длина ключа DB KEY. Это 8 байт для таблиц. Для просмотров это 8 * количество таблиц, на которые ссылается определение просмотра. Не изменяйте этот столбец. Более подробно о таких ключах см. в разд. «Темы оптимизации» в конце главы 30
RDB $ FORMAT	SMALLINT			Внутреннее использование — не модифицируйте
RDB$FIELD_ID	SMALLINT			Внутреннее использование — не модифицируйте
RDB$RELATION_NAME	CHAR(31)	Y	Y	Имя таблицы или просмотра
RDB$SECURITY_CLASS	CHAR(31)			Может ссылаться на класс безопасности, определенный В RDB$SECURITY_CLASSES для применения ограничений управления доступом для всех пользователей этого столбца
RDB$EXTERNAL_FILE	VARCHAR(253)			Полный путь к внешнему файлу данных, если присутствует
RDB$RUNTIME	BLOB SUMMARY			Описание метаданных таблицы. Внутреннее использование для оптимизации
RDB$EXTERNAL_DESCRIPTION	BLOB EFD			BLOB подтипа external type_description, текстовый тип BLOB, который может быть использован для документирования
RDB$OWNER_NAME	VARCHAR(31)			Имя пользователя — владельца (создателя) таблицы или просмотра для целей безопасности SQL
RDB$DEFAULT_CLASS	CHAR(31)			Класс безопасности по умолчанию. Применяется, когда новый столбец добавляется в таблицу
RDB$FLAGS	SMALLINT			Внутренние флаги

RDB$ROLES хранит определения ролей.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$ROLE_NAME	VARCHAR(31)	Y	Y	Имя роли
RDB$OWNER NAME	VARCHAR (31)			Имя пользователя владельца роли

RDB$SECURITY CLASSES хранит и отслеживает списки управления доступом.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$SECURITY_CLASS	CHAR(31)	Y	Y	Имя класса безопасности. Это имя должно оставаться согласованным во всех местах, где оно используется (RDB$DATABASE, RDB$RELATIONS, RDB$RELAT ION_FIELDS)
RDB$ACL	BLOBACL			Список управления доступом, связанный с классом безопасности. Перечисляет пользователей и их полномочия
RDB$DESCRIPTION	BLOB TEXT			Здесь определена документация по классу безопасности

BDB$TRANSACTIONS отслеживает транзакции с несколькими базами данных.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$TRANSACTION_ID	INTEGER	Y	Y	Уникальный идентификатор отслеживаемой транзакции
RDB$TRANSACTION STATE	SMALLINT			Состояние транзакции: зависшая (0), подтвержденная (1), отмененная (2)
RDB$TIMESTAMP	TIMESTAMP			Для будущих реализаций
RDB$TRANSACTION_ DESCRIPTION	BLOB TEXT			Подтип BLOB transaction description. Описывает подготовленную транзакцию к нескольким базам данных. Доступна в случае потери соединения, которое не может быть восстановлено

BDB$TRIGGER_MESSAGES хранит определения сообщений триггеров (системное использование).

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$TRIGGER NAME	CHAR(31)	Y		Имя триггера, с которым ассоциировано сообщение
RDB$MESSAGE_NUMBER	SMALLINT			Номер сообщения (от 1 до максимум 32 767)
RDB$MESSAGE	VARCHAR(78)			Текст сообщения триггера

RDB$TRIGGERS хранит описания всех триггеров.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$TRIGGER_NAME ¦	CHAR(31)	Y	Y	Имя триггера
RDB$RE LATI ON_N AME	CHAR(31)	Y		Имя таблицы или просмотра, для которого используется триггер
RDB$TRIGGER_SEQUENCE	SMALLINT			Последовательность (позиция) триггера. Ноль обычно означает, что последовательность не задана
RDB$TRIGGER_TYPE	SMALLINT			= BEFORE INSERT, 2 = AFTER INSERT, 3 = BEFORE UPDATE, 4 = AFTER UPDATE, 5 = BEFORE DELETE, 6 = AFTER DELETE. Триггеры на многие события (Firebird 1.5 и выше) имеют различные типы, которые используют большие номера. Фактический тип кода зависит от того, какие обрабатываются события и от порядка, в котором представляются события. (Заметим, что не существует видимых причин для того, чтобы порядок событий влиял на код trigger type)
RDB$TRIGGER_SOURCE	BLOB TEXT			Хранит PSQL исходный код триггера
RDB$TRIGGER_BLR	BLOB BLR			Хранит представление триггера в двоичном коде
RDB$DESCRIPTION	BLOB TEXT			Дополнительная документация
RDB$TRIGGER INACTIVE	SMALLINT			Является ли триггер в настоящее время неактивным (1 = неактивный, 0 = активный)
RDB$SYSTEM FLAG	SMALLINT			Определен пользователем (0) либо системой (1 или выше)
RDB$FLAGS	SMALLINT			Внутреннее использование

RDB $ TYPES хранит описания перечисляемых типов, используемых в Firebird.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$FIELD NAME	CHAR (31)			Имя столбца, для которого определен этот перечисляемый тип. Заметьте, что то же имя столбца появляется во множестве системных таблиц
RDB$TYPE	SMALLINT			Перечислимый идентификатор для типа, который идентифицирует RDB$FIELD NAME. Последовательность чисел является уникальной для каждого отдельного перечисляемого типа (например, 0 = таблица, 1 = просмотр, 2 = триггер, 3 = вычисляемый столбец, 4 = проверка, 5 = процедура — все являются типами из RDB$OBJECT TYPE)
RDB$TYPE_NAME	CHAR(31)	Y		Текстовое представление типа, идентифицированного значением RDB$FIELD_NAME и значением RDB$TYPE
RDB$DESCRIPTION	BLOB TEXT			Может использоваться для документирования
RDB$SYSTEM_FLAG	SMALLINT			Определен пользователем (0) или системой (1 или выше)

RDB$USER_PRIVILEGES хранит полномочия SQL.

Идентификатор столбца	Тип	IDX	UN	Описание
RDB$USER	CHAR(31)	Y		Пользователь, которому предоставляется полномочие
RDB$GRANTOR	CHAR(31)			Имя пользователя, предоставляющего полномочие
RDB$PRIVILEGE	CHAR(6)			Привилегия, предоставляемая в полномочии
RDB$GRANT_OPT \| ON	SMALLINT			Содержит ли полномочие авторизацию WITH GRANT OPTION. 1 = да, 0 = нет
RDB$RELATION NAME	CHAR(31)	Y		Объект, к которому предоставляется полномочие
RDB$FIELD_NAME	CHAR(31)			Имя столбца, к которому применяется привилегия на уровне столбца (только привилегии UPDATE и REFERENCES)
RDB$USER_TYPE	SMALLINT			Идентифицирует тип пользователя, которому предоставляется привилегия (например, пользователь, процедура, просмотр и т.д.)
RDB$OBJECT_TYPE	SMALLINT			Идентифицирует тип объекта, к которому предоставляется привилегия

RDB$VIEW_RELATIONS является устаревшей таблицей.

Системные просмотры

Следующие системные просмотры являются подмножеством просмотров, определенных в стандарте SQL-92. Они предоставляют полезную информацию о ваших данных. Вы можете скопировать эти тексты в скрипты и инсталлировать просмотры во всех ваших базах данных.

CHECK_CONSTRAINTS отображает все ограничения CHECK, определенные в базе данных, с исходными текстами определения ограничений.

CREATE VIEW CHECK_CONSTRAINTS (

CONSTRAINT_NAME,

CHECK_CLAUSE )

SELECT RDB$CONSTRAINT_NAME,

RDB$TRIGGER_SOURCE

FROM RDB$CHECK_CONSTRAINTS RC, RDB$TRIGGERS RT

WHERE RT.RDB$TRIGGER_NAME = RC.RDB$TRIGGER_NAME;

CQNSTRAINTS_COLUMN_USAGE отображает столбцы, используемые в ограничениях PRIMARY KEY и UNIQUE и определенные в ограничениях FOREIGN KEY.

CREATE VIEW CONSTRAINTS_COLUMN_USAGE (

TABLE_NAME,

COLUMN_NAME, CONSTRAINT_NAME )

SELECT RDB$RELATION_NAME, RDB$FIELD_NAME, RDB$CONSTRAINT_NAME

FROM RDB$RELATION_CONSTRAINTS RC, RDB$INDEX_SEGMENTS RI

WHERE RI.RDB$INDEX_NAME = RC.RDB$INDEX_NAME;

REFERENTIAL_CONSTRAINTS отображает все ссылочные ограничения, определенные в базе данных.

CREATE VIEW REFERENTIAL_CONSTRAINTS (

CONSTRAINT_NAME,

UNIQUE_CONSTRAINT_NAME,

MATCH_OPTION,

UPDATE_RULE,

DELETE_RULE )

SELECT RDB$CONSTRAINT_NAME,

RDB$CONST_NAME_UQ, RDB$MATCH_OPTION,

RDB$UPDATE_RULE, RDB$DELETE_RULE

FROM RDB$REF_CONSTRAINTS;

TABLE_CONSTRAINTS отображает ограничения на уровне таблицы.

CREATE VIEW TABLE_CONSTRAINTS (

CONSTRAINT_NAME,

TABLE_NAME,

CONSTRAINT_TYPE,

IS_DEFERRABLE,

INITIALLY_DEFERRED )

SELECT RDB$CONSTRAINT_NAME, RDB$RELATION_NAME,

RDB$CONSTRAINT_TYPE, RDB$DEFERRABLE, RDB$INITIALLY_DEFERRED

FROM RDB$RELATION CONSTRAINTS;

Приложение 10. Коды ошибок

Коды ошибок, возвращаемые клиентам или модулям PSQL сервером Firebird 1.5.0, представлены в табл. П10.1. Некоторые коды недоступны в более ранних версиях Firebird. Важно убедиться, что сервер и клиент имеют корректную версию файла firebird.msg (interbase.msg для Firebird 1.0.x), хранящегося в корневом каталоге Firebird. Необязательно копировать MSG-файл на клиентские компьютеры, но если он присутствует, то должен быть корректным.

Таблица П10.1. Коды ошибок Firebird 1.5.0

SQLCODE	GDSCODE	Символ	Текст сообщения
101	335544366	segment	-Segment buffer length shorter than expected. Длина сегмента буфера меньше, чем ожидается
100	335544338	from no match	-No match for first value expression. Нет соответствия для первого значения выражения
100	335544354	no_record	-Invalid database key. Неверный ключ базы данных
100	335544367	segstr eof	-Attempted retrieval of more segments than exist. Попытка поиска больше сегментов, чем существует
100	335544374	stream eof	-Attempt to fetch past the last record in a record stream. Попытка загрузки в поток записей после последней записи
-84	335544554	nonsql security rel	-Table/procedure has non-SQL security class defined. Для таблицы/процедуры определен класс безопасности, не являющийся SQL
-84	335544555	nonsql security fid	-Column has non-SQL security class defined. Для столбца определен класс безопасности, не являющийся SQL
-84	335544668 —	dsql_procedure use err	-Procedure <string> does not return any values. Процедура <строка> не возвращает никакого значения
-85	335544747	usrname too_long	-The username entered is too long. Maximum length is 31 bytes. Введенное имя пользователя слишком длинное. Максимальная длина 31 байт
-85	335544748	password too long	-The password specified is too long. Maximum length is 8 bytes. Указанный пароль слишком длинный. Максимальная длина 8 байт
-85	335544749	usrname required	-A username is required for this operation. Для этой операции требуется имя пользователя
-85	335544750	password required	-A password is required for this operation. Для этой операции требуется пароль
-85	335544751	bad?protocol	-The network protocol specified is invalid. Указан неверный сетевой протокол
-85	335544752	dup usrname found	-A duplicate user name was found in the .security database. В базе данных безопасности обнаружено дублирование имен пользователей
-85	335544753	usrname not found	-The user name specified was not found in the security database. Указанное имя пользователя не найдено в базе данных безопасности
-85	335544754	error adding sec record	-An error occurred while attempting to add the user. Появилась ошибка при попытке добавления пользователя
-85	335544755	error modifying sec_record	-An error occurred while attempting to modify the user record. Появилась ошибка при попытке изменения записи пользователя
-85	335544756	error_deleting_sec_record	-An error occurred while attempting to delete the user record. Появилась ошибка при попытке удаления записи пользователя
-85	335544757	error_updating_sec_db	-An error occurred while updating the security database. Появилась ошибка при изменении базы данных безопасности
-103	335544571	dsql_constant_err	-Data type for constant unknown. Неизвестен тип данных для константы
-104	335544343	invalid_blr	-Invalid request BLR at offset <number>. Неверный запрос в BLR со смещением <число>
-104	335544390	syntaxerr	-BLR syntax error: expected <string> at offset <number>, encountered <number>. Ошибка синтаксиса BLR: ожидается <строка> по смещению <число>, встречено <число>
-104	335544425	ctxinuse	-Context already in use (BLR error). Контекст находится в использовании (ошибка BLR)
-104	335544426	ctxnotdef	-Context not defined (BLR error). Контекст не определен (ошибка BLR)
-104	335544429	badparnum	-Bad parameter number. Неверный номер параметра
-104	335544440	bad msg vec	—
-104	335544456	invalid sdl	-Invalid slice description language at offset <number>. Неверный фрагмент языка описания по смещению <число>
-104	335544570	dsql_comrttand_err	-Invalid command. Неверная команда
-104	335544579	dsql_internal_err	-Internal error. Внутренняя ошибка
-104	335544590	dsql_dup_option	-Option specified more than once. Режим указан более одного раза
-104	335544591	dsql tran err	-Unknown transaction option. Неизвестный режим транзакции
-104	335544592	dsql invalid array	-Invalid array reference. Неверная ссылка на массив
-104	335544608	command end err	-Unexpected end of command. Неверное завершение команды
-104	335544612	token_err	-Token unknown. Неизвестный синтаксический элемент
-104	335544634	dsql token_unk_err	-Token unknown — line <number>, char <number>. Неизвестный синтаксический элемент — строка <число>, символ <число>
-104	335544709	dsql agg_ref err	-Invalid aggregate reference. Неверная ссылка на агрегат
-104	335544714	invalid_array_id	-Invalid blob id. Неверный идентификатор BLOB
-104	335544730	cse not_supported	-Client/Server Express not supported in this release. Client/Server Express не поддерживается в этом релизе
-104	335544743	token too long	-Token size exceeds limit. Размер синтаксического элемента превышает предел
-104	335544763	invalid string_constant	-A string constant is delimited by double quotes. Строковая константа определена в кавычках
-104	335544764	transitional date	-DATE must be changed to TIMESTAMP. DATE должно измениться В TIMESTAMP
-104	335544796	sql dialect datatype_ unsupport	-Client SQL dialect <number> does not support reference to <string> datatype. SQL-диалект <номер> клиента не поддерживает ссылку на тип данных <строка>
-104	335544798	depend on uncommitted rel	-You created an indirect dependency on uncommitted metadata. You must roll back the current transaction. Вы создали непрямую зависимость на неподтвержденные метаданные. Вы должны отменить текущую транзакцию
-104	335544821	dsql column_pos err	-Invalid column position used in the <string> clause. В предложении <строка> используется неверная позиция столбца
-104	335544822	dsql agg_where err	-Cannot use an aggregate function in a WHERE clause, use HAVING instead. Невозможно использовать агрегирующую функцию в предложении WHERE, используйте вместо этого HAVING
-104	335544823	dsql_agg_group_err	-Cannot use an aggregate function in a GROUP BY clause. Невозможно использовать агрегирующую функцию в предложении GROUP BY
-104	335544824	dsql_agg_column_err	-Invalid expression in the <string> (not contained in either an aggregate function or the GROUP BY clause). Неверное выражение в <строка> (не содержится ни в агрегирующей функции, ни в предложении GROUP BY)
-104	335544825	dsql_agg_having_err	-Invalid expression in the <string> (neither an aggregate function nor a part of the GROUP BY clause). Неверное выражение в <строка> (не агрегирующая функция, не предложение GROUP BY)
-104	335544826	dsql_agg nested_err	-Nested aggregate functions are not allowed. Вложенные агрегирующие функции недопустимы
-104	336003075	dsql transitional numeric	-Precision 10 to 18 changed from DOUBLE PRECISION in SQL dialect 1 to 64-bit scaled integer in SQL dialect 3. Точность от 10 до 18 в SQL-диалекте 1 изменена для DOUBLE PRECISION до 64-битового масштабируемого целого в SQL-диалекте 3
-104	336003077	sql db_dialect_dtype unsupport	-Database SQL dialect <number> does not support reference to <string> datatype. База данных диалекта SQL <номер> не поддерживает ссылку на тип данных <строка>
-104	336003087	dsql invalid label	-Label <string> <string> in the current scope. Метка <строка> <строка> находится в текущей области видимости
-104	336003088	dsql datatypes not comparable	-Datatypes <string> are not comparable in expression <string>. Тип данных <строка> не сравним в выражении <строка>
-105	335544702	like_escape invalid	-Invalid ESCAPE sequence. Неверная последовательность ESCAPE
-105	335544789	extract input_mismatch	-Specified EXTRACT part does not exist in input datatype. Заданная часть EXTRACT не существует во входном типе данных
-150	335544360	read only rel	-Attempted update of read-only table. Попытка изменить таблицу только для чтения
-150	335544362	read only view	-Cannot update read-only view <string>. Невозможно изменить просмотр только для чтения <строка>
-150	335544446	non updatable	-Not updatable. Не изменяется
-150	335544546	constaint_on_view	-Cannot define constraints on views. Нельзя определить ограничения для просмотра
-151	335544359	read only field	-Attempted update of read-only column. Попытка изменить столбец только для чтения
-155	335544658	dsql_base_table	-<string> is not a valid base table of the specified view. <Строка> не является допустимой базовой таблицей для указанного просмотра
-157	335544598	specify_field err	-Must specify column name for view select expression. Требуется задать имя столбца для выражения SELECT просмотра
-158	335544599	num field_err	-Number of columns does not match select list. Номера столбцов не соответствуют списку SELECT
-162	335544685	no dbkey	-Dbkey not available for multi- table views. Ключ базы данных недоступен для многотабличных просмотров
-170	335544512	prcmismat	-Parameter mismatch for procedure <string>. Несоответствие параметра для процедуры <строка>
-170	335544619	extern_func_err	-External functions cannot have more than 10 parameters. Внешняя функция не может иметь более 10 параметров
-171	335544439	funmismat	-Function <string> could not be matched. Функции <строка> нельзя найти соответствие
-171	335544458	invalid_dimens ion	-Column not array or invalid dimensions (expected <number>, encountered <number>). Столбец не является массивом или неверная размерность (ожидается <номер>, встретилось <номер>)
-171	335544618	return_mode err	-Return mode by value not allowed for this data type. Вариант возвращаемого значения недоступен для этого типа данных
-172	335544438	funnotdef	-Function <string> is not defined. Функция <строка> не определена
-203	335544708	dyn fld_ambiguous	-Ambiguous column reference. Неоднозначная ссылка на столбец
-204	335544463	gennotdef	-Generator <string> is not defined. Генератор <строка> не определен
-204	335544502	stream not defined	-Reference to invalid stream number. Ссылка на неверный номер потока
-204	335544509	charset_not found	-CHARACTER SET <string> is not defined. Набор символов <строка> не определен
-204	335544511	prcnotdef	-Procedure <stiing> is not defined. Процедура <строка> не определена
-204	335544515	codnotdef	-Status code <string> unknown. Неизвестный код состояния <строка>
-204	335544516	xcpnotdef	-Exception <string> not defined. He определено исключение <строка>
-204	335544532	ref cnstrnt_notfound	-Name of Referential Constraint not defined in constraints table. Имя ссылочного ограничения не определено в таблице ограничений
-204	335544551	grant obj_notfound	-Could not find table/procedure for GRANT. Невозможно найти таблицу/процедуру для GRANT
-204	335544568	text_subtype	-Implementation of text subtype . <number> not located. Реализация текстового подтипа <но- мер> не обнаружена
-204	335544573	dsql_datatype_err	-Data type unknown. Неизвестный тип данных
-204	335544580	dsql_relation_err	-Table unknown. Неизвестная таблица
-204	335544581	dsql procedure err	-Procedure unknown. Неизвестная процедура
-204	335544588	collation not found	-COLLATION <string> is not defined. Порядок сортировки <строка> не определен
-204	335544589	collation not for charset	-COLLATION <string> is not valid for specified CHARACTER SET.. Порядок сортировки <строка> неверен для указанного набора символов
-204	335544595	dbql_trigge r_e г г	-Trigger unknown. Неизвестный триггер
-204	335544620	alias conflict err	-Alias <string> conflicts with an alias in the same statement. Алиас <строка> конфликтует с алиасом в том же операторе
-204	335544621	procedure conflict_error	-Alias <string> conflicts with a procedure in the same statement. Алиас <строка> конфликтует с процедурой в том же операторе
-204	335544622	relation_conflict err	-Alias <string> conflicts with a table in the same statement. Алиас <строка> конфликтует с таблицей в том же операторе
-204	335544635	dsql_no relation_alias	-There is no alias or table named <string> at this scope level. Не существует указанного алиаса или таблицы <строка> на этом уровне видимости
-204	335544636	indexname	-There is no index <string> for table <string>. Не существует индекса <строка> для таблицы <строка>
-204	335544640	collation requires_text	-Invalid use of CHARACTER SET or COLLATE. Неверное использование набора символов или порядка сортировки
-204	335544662	dsql blob type unknown	-BLOB SUB_TYPE <string> is not defined. Подтип BLOB <строка> не определен
-204	335544759	bad default value	-Can not define a not null column with NOLL as default value. Невозможно определить непустой столбец (NOT NULL) вместе со значением по умолчанию NULL
-204	335544760	invalid clause	-Invalid clause-‘<string>’. Неверное предложение — ‘<строка>’
-204	335544800	too many contexts	-Too many Contexts of Relation/Procedure/Views. Maximum allowed is 127. Слишком большой контекст в отношении/процедуре/просмотре. Допустимо максимум 127
-204	335544817	bad limitjparam	-Invalid parameter to FIRST. Only integers >= 0 are allowed. Неверный параметр для FIRST. Допустимы только целые >= 0
-204	335544818	bad skipjparam	-Invalid parameter to SKIP. Only integers >= 0 are allowed. Неверный параметр для SKIP. Допустимы только целые >= 0
-204	336003085	dsql ambiguous field_name	-Ambiguous field name between <string> and <string>. Двусмысленность имени поля между <строка> и <строка>
-205	335544396	fldnotdef	-Column <string> is not defined in table <string>. Столбец <строка> не определен в таблице <строка>
-205	335544552	grant fid notfound	-Could not find column for GRANT. Невозможно найти столбец для GRANT
-206	335544578	dsql_field_err	-Column unknown. Неизвестный столбец
-206	335544587	dsql blob err	-Column is not a BLOB. Столбец не является BLOB
-206	335544596	dsql_subselect_err	-Subselect illegal in this context. Вложенный оператор SELECT неверен в данном контексте
-208	335544617	order by err	-Invalid ORDER BY clause. Неверное предложение ORDER BY
-219	335544395	relnotdef	-Table <string> is not defined. Таблица <строка> не определена
-239	335544691	cache too small	-Insufficient memory to allocate page buffer cache. Недостаточно памяти для выделения кэша под буфер страницы
-260	335544690	cache_redef	-Cache redefined. Переопределение кэша
-281	335544637	no stream_jplan	-Table <string> is not referenced in plan. Таблиц <строка> не указана в плане
-282	335544638	stream twice	-Table <string> is referenced more than once in plan; use aliases to distinguish. На таблицу <строка> осуществляются ссылки более одного раза в плане; используйте алиасы для различения
-282	335544643	ds ql_s elf_j oin	-The table <string> is referenced twice; use aliases to differentiate. На таблицу <строка> в плане осуществляются ссылки дважды; используйте алиасы для разыменования
-282	335544659	duplicate base_table	-Table <string> is referenced twice in view; use an alias to distinguish. На таблицу <строка> в просмотре осуществляются ссылки дважды; используйте алиас для различения
-282	335544660	view_alias	-View <string> has more than one base table; use aliases to distinguish. Просмотр <строка> имеет более одной базовой таблицы; используйте алиасы для различения
-282	335544710	complex view	-Navigational stream <number> references a view with more than one base table. Поток навигации <строка> ссылается на просмотр с более чем одной базовой таблицей
-283	335544639	stream_not_found	-Table <string> is referenced in the plan but not the from list. На таблицу <строка> есть ссылки в плане, однако она не указана в списке
-284	335544642	-index unused	-Index <string> cannot be used in the specified plan. Индекс <строка> не может быть использован в указанном плане
-291	335544531	primary_key_notnull	-Column used in a PRIMARY KEY constraint must be NOT NOLL. Столбец, используемый в ограничении первичного ключа, должен быть NOT NULL
-292	335544534 1	ref cnstrnt update	-Cannot update constraints (RDB$REF_CONSTRAINTS). Нельзя изменять ограничения (RDB$REF CONSTRAINTS)
-293	335544535	check_cnstrnt_update	-Cannot update constraints (RDB$CHECK_CONSTRAINTS). Нельзя изменять ограничения (RDB$REF_CONSTRAINTS)
-294	335544536	check cnstrnt del	-Cannot delete CHECK constraint entry (RDB$CHECK_CONSTRAINTS). Нельзя удалять запись ограничения CHECK (RDB$REF_CONSTRAINTS)
-295	335544545	rel cnstrnt update	-Cannot update constraints (RDB$RELATION_CONSTRAINTS) . Нельзя изменять ограничения (RDB$RELATION_CONSTRAINTS)
-296	335544547	invld_cnstrnt_type	-Internal gds software consistency check (invalid RDB$CONSTRAINT_TYPE). Проверка внутреннего программного обеспечения gds (неверный RDB$CONSTRAINT_YYPE)
-297	335544558	check constraint	-Operation violates CHECK constraint <string> on view or table <stiing>. Операция нарушает ограничение CHECK <строка> для просмотра или таблицы <строка>
-313	335544669	dsql count mismatch	-Count of column list and variable list do not match. Количество столбцов в списке и список переменных не соответствуют друг другу
-314	335544565	transliteration failed	-Cannot transliterate character between character sets. Невозможно выполнить транслитерацию символов между наборами символов
-315	336068815	dyn dtype invalid	-Cannot change datatype for column <string>. Changing datatype is not supported for BLOB or ARRAY columns. Невозможно изменить тип данных для столбца <строка>. Изменение типа данных не поддерживается для столбцов BLOB и массивов
-383	336068814	dyn dependency exists	-Column <string> from table <string> is referenced in <string>. На столбец <строка> из таблицы <строка> есть ссылка в <строка>
-401	335544647	invalid_operator	-Invalid comparison operator for find operation. Неверный оператор сравнения для операции
-402	335544368	segstr_no_op	-Attempted invalid operation on a BLOB. Попытка использования неверной операции для BLOB
-402	335544414	blobnotsup	-BLOB and array data types are not supported for <string> operation. Типы данных BLOB и массивы не поддерживаются для операции <строка>
-402	335544427	datnotsup	-Data operation not supported. Операция с данными не поддерживается
-406	335544457	out of_bounds	-Subscript out of bounds. Выход за пределы диапазона
-407	335544435	nullsegkey	-Null segment of UNIQUE KEY. Пустой сегмент для уникального ключа
-413	335544334	convert error	-Conversion error from string «<string>». Ошибка преобразования для строки ‘<строка>’
-413	335544454	nofilter	-Filter not found to convert type <number> to type <number>. Не найден фильтр для преобразования типа <номер> в тип <номер>
-501	335544327	bad_req_handle	-Invalid request handle. Неверный запрос дескриптора
-501	335544577	dsql cursor close err	-Attempt to reclose a closed cursor. Попытка повторного закрытия закрытого курсора
-502	-335544574	-dsql decl err	-Declared cursor already exists. Объявляемый курсор уже существует
-502	-335544576	-dsql cursor_open err	-Attempt to reopen an open cursor. Попытка повторного открытия открытого курсора
-504	-335544572	-dsql_cursor_err	-Cursor unknown. Неизвестный курсор
-508	-335544348	-no_cur_rec	-No current record for fetch operation. Нет текущей записи для операции загрузки
-510	-335544575	-dsql cursor update err	-Cursor not updatable. Курсор не является изменяемым
-518	-335544582	-dsql request err	-Request unknown. Неизвестный запрос
-519	-335544688	-dsql open cursor request	-The prepare statement identifies a prepare statement with an open cursor. Оператор подготовки идентифицировал оператор подготовки для открытого курсора
-530	-335544466	-foreign_key	-Violation of FOREIGN KEY constraint «<string>» on table «<string>». Нарушение ограничения внешнего ключа «<строка>» для таблицы «<строка>»
-531	-335544597	-dsql crdb_prepare err	-Cannot prepare a CREATE DATABASE/SCHEMA statement. Невозможно подготовить оператор CREATE DATABASE/SCHEMA
-532	-335544469	-trans invalid	-Transaction marked invalid by I/O error. Транзакция отмечена как ошибочная из-за ошибки ввода/вывода
-551	-335544352	-no_priv	-No permission for <string> access to <string> <string>. Не существует полномочий для доступа <строка> к <строка>
-551	-335544790	-insufficient svcjorivile ges	-Service <string> requires SYSDBA permissions. Reattach to the Service Manager using the SYSDBA account. Сервис <строка> требует полномочий SYSDBA. Соединитесь с Менеджером сервисов как пользователь SYSDBA
-552	-335544550	i-not rel owner	-Only the owner of a table may reassign ownership. Только владелец таблицы может переназначать владение
-552	-335544553	-grant nopriv	-User does not have GRANT privileges for operation. Пользователь не имеет назначенных привилегий для операции
-552	-335544707	-grant nopriv on base	-User does not have GRANT privileges on base table/view for operation. Пользователь не имеет назначенных привилегий к базовой таблице/просмотру для операции
-553	-335544529	-existing_priv mod	-Cannot modify an existing user privilege. Невозможно изменить существующую привилегию пользователя
-595	-335544645	-stream crack	-The current position is on a crack. Текущая позиция разрушена
-596	-335544644	-stream bof	-Illegal operation when at beginning of stream. Операция некорректна, поскольку указатель на позицию в потоке ссылается на начало потока
-597	-335544632	-dsql_file length err	-Preceding file did not specify length, so <string> must include starting page number. Предыдущий файл не содержит длины, следовательно, <строка> должен включать начальный номер страницы
-598	-335544633	-dsql_shadow number err	-Shadow number must be a positive integer. Номер теневой копии должен быть положительным целым числом
-599	-335544607	-node err	-Gen.с: node not supported. Узел Gen, с не поддерживается
-599	-335544625	-node name err	-A node name is not permitted in a secondary, shadow, cache or log file name. Имя узла не разрешено во вторичном файле, файле теневой копии, кэше или файле протокола
-600	-335544680	-crrp data err	-Sort error: corruption in data structure. Ошибка сортировки: разрушение структуры данных
-601	-335544646	-db or file exists	-Database or file exists. Существует база данных или файл
-604	-335544593	-dsql max arr dim exceede d	-Array declared with too many dimensions. Объявлен массив слишком большой размерности
-604	-335544594	-dsql arr range error	-Illegal array dimension range. Неверный диапазон размерности массива
-605	-335544682	-dsql_field_ref	-Inappropriate self-reference of column. Несоответствующая ссылка столбца на самого себя
-607	-335544351	-no_meta update	-Unsuccessful metadata update. Ошибочное изменение метаданных
-607	-335544549	-systrig update	-Cannot modify or erase a system trigger. Невозможно изменить или удалить системный триггер
-607	-335544657	-dsql no blob array	-Array/BLOB/DATE data types not allowed in arithmetic. Типы данных МАССИВ/BLOB/DATE недопустимы в арифметических операциях
-607	-335544746	-reftable requires_pk	-«REFERENCES table» without «(column)» requires PRIMARY KEY on referenced table. «REFERENCES таблица» без указания столбца требует первичного ключа в таблицу, на которую осуществляется ссылка
-607	-335544815	-generator name	-GENERATOR <string>. Генератор <строка>
-607	-335544816	-udf name	-UDF <string>. UDF <строка>
-607	-336003074	-dsql_dbkey_fram_non_table	-Cannot SELECT RDB$DB_KEY from a stored procedure. Невозможно выполнить SELECT RDB$DB_KEY из хранимой процедуры
-607	-336003086	?-dsql udf return_pos err	-External function should have return position between 1 and <number>. Внешняя функция должна иметь позицию возвращаемого значения между 1 и <номер>
-612	-336068812	-dyn_domain_name exists	-Cannot rename domain <string> to <string>. A domain with that name already exists. Невозможно переименовать домен <строка> в <строка>. Домен с этим именем уже существует
-612	-336068813	-dyn field name exists	-Cannot rename column <string> to <string>. A column with that name already exists in table <string>. Невозможно переименовать столбец <строка> в <строка>. Столбец с этим именем уже существует в таблице <строка>
-615	-335544475	-relation lock	-Lock on table <string> conflicts with existing lock. Блокировка таблицы <строка> конфликтует с существующей блокировкой
-615	-335544476	-record_lock	-Requested record lock conflicts with existing lock. Запрашиваемая блокировка записи конфликтует с существующей блокировкой
-615	-335544507	-range in_use	-Refresh range number <number> already in use. Обновляемый диапазон <номер> уже находится в использовании
-616	-335544530	-primary key ref	-Cannot delete PRIMARY KEY being used in FOREIGN KEY definition. Невозможно удалить первичный ключ, используемый в определении внешнего ключа
-616	-335544539	-integ index del	-Cannot delete index used by an Integrity Constraint. Невозможно удалить индекс, используемый в ограничении целостности
-616	-335544540	-integ_index_mod	-Cannot modify index used by an Integrity Constraint. Невозможно изменить индекс, используемый в ограничении целостности ?3?
-616	-33554454?	-check trig del	-Cannot delete trigger used by a CHECK Constraint. Невозможно удалить триггер, используемый в ограничении CHECK
-616	-335544543	-cnstrnt_fld_del	-Cannot delete column being used in an Integrity Constraint. Невозможно удалить столбец, используемый в ограничении целостности
-616	-335544630	-dependency	-There are <number> dependencies. Существуют зависимости <номер>
-616	-335544674	-del_last field	-Last column in a table cannot be deleted. Последний столбец в таблице не может быть удален
-616	-335544728	-integ index deactivate	-Cannot deactivate index used by an Integrity Constraint. Невозможно деактивировать триггер, используемый в ограничении целостности
-616	-335544729	-integ_deactivate_primary	-Cannot deactivate primary index. Невозможно деактивировать первичный индекс
-617	-335544542	— che с k_t r i g_upda t e	-Cannot update trigger used by a CHECK Constraint. Невозможно обновить триггер, используемый в ограничении CHECK
-617	-335544544	-cnstrnt_fld_rename	-Cannot rename column being used in an Integrity Constraint. Невозможно переименовать столбец, используемый в ограничении целостности
-618	-335544537	-integ_index_seg del	-Cannot delete index segment used by an Integrity Constraint. Невозможно удалить сегмент индекса, используемый в ограничении целостности
-618	-335544538	-integ index seg mod	-Cannot update index segment used by an Integrity Constraint. Невозможно изменить сегмент индекса, используемый в ограничении целостности
-625	-335544347	-lot valid	-Validation error for column <string>, value «<string>». Ошибка проверки для столбца <строка>, значение «<строка>»
-637	-335544664	-dsql duplicate spec	-Duplicate specification of <string> — not supported. Дублирование спецификации для <строка> не поддерживается
-660	-335544533	-foreign key notfound	-Non-existent PRIMARY or UNIQUE KEY specified for FOREIGN KEY. Не существует первичный или уникальный ключ, указанный для внешнего ключа
-660	-335544628	-idx create err	-Cannot create index <string>. Невозможно создать индекс <строка>
-663	-335544624	-idx seg err	-Segment count of 0 defined for index <string>. Счетчик сегментов 0 определен для индекса <строка>
-663	-335544631	-idx key err	-Too many keys defined for index <string>. Слишком много ключей определено для индекса <строка>
-663	-335544672	-key field err	-Too few key columns found for index <string> (incorrect column name?). Слишком мало ключевых столбцов найдено для индекса <строка> (неверное имя столбца?)
-664	-335544434	-keytoobig	-Key size exceeds implementation restriction for index «<string>». Размер ключа превышает ограничения реализации для индекса «<строка>»
-677	-335544445	-ext err	-<string> extension error/ Ошибка расширения <строка>
-685	-335544465	-bad segstr type	-Invalid BLOB type for operation. Неверный тип BLOB для операции
-685	-335544670	-blob idx err	-Attempt to index BLOB column in index <string>. Попытка включить столбец BLOB в индекс <строка>
-685	-335544671	-array_idx_err	-Attempt to index array column in index <string>. Попытка включить столбец массива в индекс <строка>
-689	-335544403	-badpagtyp	-Page <numbe2T> is of wrong type (expected <number>, found <number>) . Страница <номер> имеет неверный тип (ожидается <номер>, найдено <номер>)
-689	-335544650	-page_type_err	-Wrong page type. Неверный тип страницы
-690	-335544679	-no segments_err	-Segments not allowed in expression index <string>. Сегменты недоступны в индексном выражении <строка>
-691	-335544681	-rec size err	-New record size of <number> bytes is too big. Новая запись размера <число> байт слишком велика
-692	-335544477	-max_idx	-Maximum indexes per table (<number>) exceeded. Превышено максимальное количество индексов для таблицы (<число>)
-693	-335544663	-req_max clones exceeded	-Too many concurrent executions of the same request. Слишком много выполнений того же самого запроса
-694	-335544684	-no field access	-Cannot access column <string> in view <strlng>. Невозможен доступ к столбцу <строка> в просмотре <строка>
-802	-335544321	-arith except	-Arithmetic exception, numeric overflow, or string truncation. Арифметическое исключение, числовое переполнение или усечение строки
-803	-335544349	-no dup	-Attempt to store duplicate value (visible to active transactions) in unique index «<string>». Попытка сохранения дубликата значения (видимого в активной транзакции) в уникальном индексе <строка>
-803	-3355446651	-unique key violation	-Violation of PRIMARY or UNIQUE KEY constraint «<string>» on table «<string>». Нарушение ограничения «<строка>» для первичного или уникального ключа для таблицы «<строка>»
-804	-335544380	-wronumarg	-Wrong number of arguments on call. Неверное количество аргументов при вызове
-804	-335544583	-dsql_sqlda_err	-SQLDA missing or incorrect version, or incorrect number/type of variables. SQLDA отсутствует или имеет неверную версию либо неверное количество или тип переменных
-804	-335544586	-dsql_function_err	-Function unknown. Неизвестная функция
-804	-335544713	-dsql sqlda value_err	-Incorrect values within SQLDA structure. Неверные значения в структуре SQLDA
-806	-335544600	-col name err	-Only simple column names permitted for VIEW WITH CHECK OPTION. Только простые имена столбцов допустимы В VIEW WITH CHECK OPTION
-807	-335544601	-where_err	-No WHERE clause for VIEW WITH CHECK OPTION. Нет предложения WHERE для VIEW WITH CHECK OPTION
-808	-335544602	-table view err	-Only one table allowed for VIEW WITH CHECK OPTION. Только одна таблица допустима для VIEW WITH CHECK OPTION
-809	-335544603	-distinct err	-DISTINCT, GROUP or HAVING not permitted for VIEW WITH CHECK OPTION. Не разрешены DISTINCT, GROUP или HAVING В VIEW WITH CHECK OPTION
-810	-335544605	-subquery err	-No subqueries permitted for VIEW WITH CHECK OPTION. Не позволены подзапросы для VIEW WITH CHECK OPTION
-811	-335544652	-sing select_err	-Multiple rows in singleton select. Множество строк в одиночном SELECT
-816	-335544651	-ext readonly_err	-Cannot insert because the file is readonly or is on a read only medium. Невозможно добавление, потому что файл является файлом только для чтения или располагается на устройстве только для чтения
-816	-335544715	-extfile uns_op	-Operation not supported for EXTERNAL FILE table <string>. Операция не поддерживается для таблицы внешнего файла <строка>
-817	-335544361	-read only trans	-Attempted update during readonly transaction. Попытка изменения при транзакции только для чтения
-817	-335544371	-segstr no write	-Attempted write to read-only BLOB. Попытка записи в BLOB только для чтения
-817	-335544444	-read only	-Operation not supported. Операция не поддерживается
-817	-335544765	-read only_database	-Attempted update on read-only database. Попытка изменения базы данных только для чтения
-817	-335544766	-must be dialect_2_and up	-SQL dialect <string> is not supported in this database. Диалект SQL <строка> не поддерживается в этой базе данных
-817	-335544793	-ddl not allowed_by_db sq 1 dial	-Metadata update statement is not allowed by the current database SQL dialect <number>. Оператор изменения метаданных недопустим в текущем диалекте SQL базы данных <строка>
-817	-336003079	-isc sql dialect_conflict num	-DB dialect <number> and client dialect <number> conflict with respect to numeric precision <number>. Диалект базы данных <число> и диалект клиента <число> конфликтуют в отношении точности чисел <строка>
-820	-335544356	-obsolete metadata	-Metadata is obsolete. Устаревшие метаданные
-820	-335544379	-wrong ods	-Unsupported on-disk structure for file <string>; found <number>, support <number>. Неподдерживаемая структура на диске (ODS) для файла <строка> найдено <номер>, поддерживается <номер>
-820	-335544437	-wrodynver	-Wrong DYN version. Неверная версия DYN
-820	-335544467	-high minor	-Minor version too high found <number> expected <number>. Найдена слишком высокая минимальная версия <номер>, ожидается <номер>
-823	-335544473	-invalid_bookmark	-Invalid bookmark handle. Неверный дескриптор закладки
-824	-335544474	-bad lock_level	-Invalid lock level <number>. Неверный уровень блокировки <номер>
-825	-335544519	-bad_lock handle	-Invalid lock handle. Неверный дескриптор блокировки
-826	-335544585	-dsql stmt handle	-Invalid statement handle. Неверный дескриптор оператора
-827	-335544655	-invalid_direction	-Invalid direction for find operation. Неверное направление для операции поиска
-827	-335544718	-invalid key	-Invalid key for find operation. Неверный ключ для операции поиска
-828	-335544678	-inval keyjposn	-Invalid key position. Неверная позиция ключа
-829	-335544616	-field ref err	-Invalid column reference. Неверная ссылка на столбец
-829	-336068816	-dyn char fid too small	-New size specified for column <string> must be at least <number> characters. Указанный новый размер для столбца <строка> должен иметь, по меньшей мере, <номер> символов
-829	-336068817	-dyn invalid dtype conversion	-Cannot change datatype for <string>. Conversion from base type <string> to <string> is not supported. Невозможно изменить тип данных для <строка>. Преобразование из базового типа <строка> в <строка> не поддерживается
-829	-336068818	-dyn dtype conv_invalid	-Cannot change datatype for column <string> from a character type to a non-character type. Невозможно изменить тип данных для столбца <строка> из набора символов в тип, не имеющий набора символов
-830	-335544615	-field aggregate err	-Column used with aggregate. Столбец используется в агрегате
-831	-335544548	-primary key exists	-Attempt to define a second PRIMARY KEY for the same table. Попытка определения второго первичного ключа для той же таблицы
-832	-335544604	-key field count err	-FOREIGN KEY column count does not match PRIMARY KEY. Количество столбцов внешнего ключа не соответствует первичному ключу
-833	-335544606	-expression eval err	-Expression evaluation not supported. Вычисление выражения не поддерживается
-833	-335544810	-date range exceeded	-Value exceeds the range for valid dates. Значение превышает диапазон допустимых дат
-834	-335544508	-range not_found	-Refresh range number <number> not found. Номер диапазона обновления <номер> не найден
-835	-335544649	-bad checksum	-Bad checksum. Ошибочная контрольная сумма
-836	-335544517	-except	-Exception <number>. Исключение <номер>
-837	-335544518	-cache_restart	-Restart shared cache manager. Повторный запуск менеджера совместно используемогокэша
-838	-335544560	-shutwarn	-Database <string> shutdown in <number> seconds. База данных <строка> остановлена на <номер> секунд
-841	-335544677	-version err	-Too many versions. Слишком много версий
-842	-335544697	-precision_err	-Precision must be from 1 to 18. Точность должна быть между 1 и 18
-842	-335544698	-scale nogt	-Scale must be between zero and precision. Масштаб должен быть между нулем и точностью
-842	-335544699	-expec short	-Short integer expected. Ожидается короткое целое
-842	-335544700	-expec_long	-Long integer expected. Ожидается длинное целое
-842	-335544701	-expec ushort	-Unsigned short integer expected. Ожидается беззнаковое короткое целое
-842	-335544712	-expec_positive	-Positive value expected. Ожидается положительное значение
-901	-335544322	-bad_dbkey	-Invalid database key. Неверный ключ базы данных
-901	-335544326	-bad dpb form	-Unrecognized database parameter block. Нераспознанный блок параметров базы данных
-901	-335544328	-bad segstr handle	Invalid BLOB handle. Неверный дескриптор BLOB
-901	-335544329	-bad_segstr id	Invalid BLOB ID. Неверный идентификатор BLOB
-901	-335544330	-bad_tpb content	-Invalid parameter in transaction parameter block. Неверный параметр в блоке параметров транзакции
-901	-335544331	-bad_tpb_form	-Invalid format for transaction parameter block. Неверный формат блока параметров транзакции
-901	-335544332*	-bad_trans handle	-Invalid transaction handle (expecting explicit transaction start). Неверный дескриптор транзакции (ожидается явный запуск транзакции)
-901	-335544337	-excess trans	-Attempt to start more than <number> transactions. Попытка запуска более чем <номер> транзакций
-901	-335544339	-infinap	-Information type inappropriate for object specified. Информационный тип не соответствует указанному объекту
-901	-335544340	-infona	-No information of this type available for object specified. Никакой информационный тип не доступен для указанного объекта
-901	-335544341	-infunk	-Unknown information item. Неизвестный информационный элемент
-901	-335544342	-integ_fail	-Action cancelled by trigger (<number>) to preserve data integrity. Отменено действие в триггере (<номер>) для сохранения целостности данных
-901	-335544345	-lock conflict	-Lock conflict on no wait transaction. Конфликт блокировки для транзакции NO WAIT
-901	-335544350	-no_finish	-Program attempted to exit without finishing database. Программа пытается завершиться без закрытия базы данных
-901	-335544353	-no_recon	-Transaction is not in limbo. Транзакция не является зависшей
-901	-335544355	-no segstr_close	-BLOB was not closed. BLOB не был закрыт
-901	-335544357	-open_trans	-Cannot disconnect database with open transactions (<number> active). Невозможно отключиться от базы данных при наличии открытой транзакции (активная <номер>)
-901	-335544358	-port_len	-Message length error (encountered <number>, expected <number>) . Ошибка длины сообщения (встречена <число>, ожидается <число>)
-901	-335544363	-req_no trans	-No transaction for request. Для запроса нет транзакции
-901	-335544364	-req_sync	-Request synchronization error. Ошибка синхронизации запроса
-901	-335544365	-req_wrong db	-Request referenced an unavailable database. Запрос ссылается на недоступную базу данных
-901	-335544369	-segstr_no_read	-Attempted read of a new, open BLOB. Попытка чтения нового, открытого BLOB
-901	-335544370	-segstr no trans	-Attempted action on blob outside transaction. Попытка действий с BLOB за пределами транзакции
-901	-335544372	-segstr_wrong db	-Attempted reference to BLOB in unavailable database. Попытка ссылки на BLOB в недоступной базе данных
-901	-335544376	-unres rel	-Table <string> was omitted from the transaction reserving list. Таблица <строка> была опущена в зарезервированном списке транзакции
-901	-335544377	-uns_ext	-Request includes a DSRI extension not supported in this implementation. Запрос включает расширение DSRI, не поддерживаемое в этой реализации
-901	-335544378	-wish_list	-Feature is not supported. Возможность не поддерживается
-901	-335544382	-random	-<string>. <строка>
-901	-335544383	-fatal conflict	-Unrecoverable conflict with limbo transaction <number>. Неперекрываемый конфликт с зависшей транзакцией <число>
-901	-335544392	-bdbincon	-Internal error. Внутренняя ошибка
-901	-335544407	-dbbnotzer	-Database handle not zero. Дескриптор базы данных не ноль
-901	-335544408	-tranotzer	-Transaction handle not zero. Дескриптор транзакции не ноль
-901	-335544418	-trainlim	-Transaction in limbo. Зависшая транзакция
-901	-335544419	-notinlim	-Transaction not in limbo. Транзакция не зависшая
-901	-335544420	-traoutsta	-Transaction outstanding. Ожидающая выполнения транзакция
-901	-335544428	-badmsgnum	-Undefined message number. Неопределенный номер сообщения
-901	-335544431	-blocking signal	-Blocking signal has been received. Был получен сигнал блокировки
-901	-335544442	-noargacc_read	-Database system cannot read argument <number>. Система базы данных не может читать аргумент <число>
-901	-335544443	-noargacc_write	-Database system cannot write argument <number>. Система базы данных не может писать аргумент <число>
-901	-335544450	-misc interpreted	-<string>. <строка>
-901	-335544468	-tra state	-Transaction <number> is <string> ¦ Транзакция <число> является <строка>
-901	-335544485	-bad stmt_handle	-Invalid statement handle. Неверный дескриптор оператора
-901	-335544510	-lock timeout	-Lock time-out on wait transaction. Истечение времени ожидания блокировки для транзакции WAIT
-901	-335544559	-bad svc_handle	-Invalid service handle. Неверный дескриптор сервиса
-901	-335544S61	-wrospbver	-Wrong version of service parameter block. Неверная версия блока параметра сервиса
-901	-335544562	-bad_spb_form	-Unrecognized service parameter block. Нераспознанный блок параметров сервиса
-901	-335544563	-svcnotdef	-Service <string> is not defined. Сервис <строка> не определен
-901	-335544609	-index name	-INDEX <string>. Индекс <строка>
-901	-335544610	-exception_name	-EXCEPTION <string>. Исключение <строка>
-901	-335544611	-field_name	-COLUMN <string>. Столбец <строка>
-901	-335544613	-union_err	-Union not supported. Объединение не поддерживается
-901	-335544614	-dsql_construct err	-Unsupported DSQL construct. Неподдерживаемая конструкция DSQL
-901	-335544623	-dsql_domain err	-Illegal use of keyword VALUE. Неверное использование ключевого слова VALUE
-901	-335544626	-table name	-TABLE <string>. Таблица <строка>
-901	-335544627	-proc_name	-PROCEDURE <string>. Процедура <строка>
-901	-335544641	-dsql domain not found	-Specified domain or source column <string> does not exist. Указанный домен или исходный столбец <строка> не существует
-901	-335544656	-dsql_var conflict	-Variable <string> conflicts with parameter in same procedure. Переменная <строка> конфликтует с параметром в той же процедуре
-901	-335544666	-srvr_version_too_old	-Server version too old to support all CREATE DATABASE options. Версия сервера слишком старая для поддержки всех режимов CREATE DATABASE
-901	-335544673	-no delete	-Cannot delete. Удаление невозможно
-901	-335544675	-sort err	-Sort error. Ошибка сортировки
-901	-335544703	-svpnoexe	-Service <string> does not have an associated executable. Сервис <строка> не имеет связанного исполняемого модуля
-901	-335544704	-net lookup err	-Failed to locate host machine. Ошибка в локализации хост-машины
-901	-335544705	— s e rvi ce_un known	-Undefined service <string>/<string>. Не определен сервис <cmpo- ка>/<строка>
-901	-335544706	-host unknown	-The specified name was not found in the hosts file or Domain Name Services. Указанное имя не было найдено в файле hosts или в сервисе имен доменов
-901	-335544711	-unprepared stmt	-Attempt to execute an unprepared dynamic SQL statement. Попытка выполнения неподготовленного оператора динамического SQL
-901	-335544716	-svc in use	-Service is currently busy: <string>. В настоящий момент сервис занят
-901	-335544731	-tra_must sweep	—
-901	-335544740	-udf_exception	-A fatal exception occurred during the execution of a user defined function. Возникло фатальное исключение в процессе выполнения функции, определенной пользователем
-901	-335544741	-lost db connection	-Connection lost to database. Потеряно соединение с базой данных
-901	-335544742	-no write user_priv	-User cannot write to RDB$USER_PRIVILEGES. Пользователь не может писать в RDB$USER PRIVILEGES
-901	-335544767	-blob filter exception	-A fatal exception occurred during the execution of a blob filter. Возникло фатальное исключение в процессе выполнения фильтра BLOB
-901	-335544768	-exception_access_ violation	-Access violation. The code attempted to access a virtual address without privilege to do so. Нарушение доступа. Код пытается получить доступ к виртуальному адресу без соответствующих привилегий
-901	-335544769		-Datatype misalignment. The attempted to read or write a value that was not stored on a memory boundary. Неверное выравнивание типа данных. Попытка читать или писать значение, которое не было сохранено в нужных границах памяти
-901	-335544770		-Array bounds exceeded. The code attempted to access an array element that is out of bounds. Превышены размеры массива. Код пытается получить доступ к элементу массива, который находится за пределами его границ
-901	-335544771		-Float denormal operand. One of the floating-point operands is too small to represent a standard float value. Ненормализованный операнд для числа с плавающей точкой. Один из операндов, ссылающихся на число с плавающей точкой, слишком мал для представления стандартного значения с плавающей точкой
-901	-335544772	-exception float divide by zero	-Floating-point divide by zero. The code attempted to divide a floating-point value by zero. Деление числа с плавающей точкой на ноль. Код пытается разделить значение с плавающей точкой на ноль
-901	-335544773(	-exception float inexact_ result	-Floating-point inexact result. The result of a floating-point operation cannot be represented as a decimal fraction. Неточный результат для числа с плавающей точкой. Результат операции для чисел с плавающей точкой не может быть представлен в виде десятичной дробной части
-901	-335544774	-exception float invalid operand	-Floating-point invalid operand. An indeterminant error occurred during a floating-point operation. Неверный операнд в операции с плавающей точкой. Неопределенная ошибка возникает в процессе операции с числами с плавающей точкой
-901	-335544775	-exception float_overflow	-Floating-point overflow. The exponent of a floating-point operation is greater than the magnitude allowed. Переполнение числа с плавающей точкой. Экспонента операции с числами с плавающей точкой больше, чем доступные размеры
-901	-335544776	-exception float_stack check	-Floating-point stack check. The stack overflowed or underflowed as the result of a floating-point operation. Проверка стека чисел с плавающей точкой. Переполнение стека или потеря значащих разрядов является результатом операции с числами с плавающей точкой
-901	-335544777	-exception_float_underflow	-Floating-point underflow. The exponent of a floating-point operation is less than the magnitude allowed. Потеря значащих разрядов числа с плавающей точкой. Экспонента операции с плавающей точкой меньше, чем допустимый размер
-901	-335544778		-Integer divide by zero. The code attempted to divide an integer value by an integer divisor of zero. Деление целого на ноль. Код пытается разделить целое значение на целый делитель, который является нулем
-901	-335544779,	-exception_integer_ overflow	-Integer overflow. The result of an integer operation caused the most significant bit of the result to carry. Целочисленное переполнение. Результат операции над целыми числами дает больше знаков, чем может храниться
-901	-335544780	-exception unknown	-An exception occurred that does not have a description. Exception number %X. Появилось исключение, не имеющее дескриптора. Исключение с номером %x
-901	-335544781	-except.ion_stack overflow	-Stack overflow. The resource requirements of the runtime stack have exceeded the memory available to it. Переполнение стека. Требуемые для стека ресурсы во время выполнения исчерпали доступную память
-901	-335544782	-exception sigsegv	-Segmentation Fault. The code attempted to access memory without privileges. Ошибка сегментирования. Код пытается получить доступ к памяти без привилегий
-901	-335544783	-exception_sigill	-Illegal Instruction. The Code attempted to perform an illegal operation. Неверная операция. Код пытается выполнить неверную операцию
-901	-335544784	-exception sigbus	-Bus Error. The Code caused a system bus error. Ошибка канала. Выполнение кода приводит к системной ошибке канала
-901	-335544785	-exception_sigfpe	-Floating Point Error. The Code caused an Arithmetic Exception or a floating point exception. Ошибка десятичной точки. Код выдает арифметическое исключение или исключение десятичной точки
-901	-335544786	-ext file_delete	-Cannot delete rows from external files. Невозможно удалить строки из внешних файлов
-901	-335544787	-ext file_modify	-Cannot update rows in external files. Невозможно изменить строки во внешних файлах
-901	-335544788	-adm task denied	-Unable to perform operation. You must be either SYSDBA or owner of the database. Невозможно выполнить операцию. Вы должны быть или пользователем SYSDBA, либо владельцем базы данных
-901	-335544794	-cancelled	-Operation was cancelled. Операция была отменена
-901	-335544797	-svcnouser	-User name and password are required while attaching to the services manager. Требуются имя пользователя и пароль при подключении к Менеджеру сервисов
-901	-335544801	-datype_notsup	-Data type not supported for arithmetic. Тип данных не поддерживается для арифметических действий
-901	-335544803	-dialect_not changed	-Database dialect not changed. Диалект базы данных не был изменен
-901	-335544804	-database create failed	-Unable to create database <string>. Невозможно создать базу данных <строка>
-901	-335544805	-inv dialect specified	-Database dialect <number> is not a valid dialect. Диалект базы данных <число> не является правильным диалектом
-901	-335544806	-valid_db_dialects	-Valid database dialects are <string>. Допустимыми диалектами базы данных являются <строка>
-901	-335544811	-inv_client_dialect_speci fied	-Passed client dialect <number> is not a valid dialect. Переданный клиентом диалект <число> не является верным диалектом
-901	-335544812	-valid_client_dialects	-Valid client dialects are <string>. Допустимыми клиентскими диалектами являются <строка>
-901	-335544814	-service_not supported	-Services functionality will be supported in a later version of the product Функциональность сервисов будет поддерживаться на более поздних версиях продукта
-901	-335740929	-gfix db name	-Data base file name (<string>) already given. Имя файла базы данных (<строка>) уже предоставлено
-901	-335740930	-gfix_invalid_sw	-Invalid switch <string>. Неверный переключатель <строка>
-901	-335740932	-gfix incmp sw	-Incompatible switch combination. Несовместимая комбинация переключателей
-901	-335740933	-gfix_replay_req	-Replay log pathname required. Требуется путь к протоколу
-901	-335740934	-gfix pgbuf req	-Number of page buffers for cache required. Требуется буфер страниц для кэша
-901	-335740935	-gfix val req	-Numeric value required. Требуется числовое значение
-901	-335740936	-gfix_pval req	-Positive numeric value required. Требуется положительное числовое значение
-901	-335740937	-gfix trn_req	-Number of transactions per sweep required. Требуется номер транзакции для чистки
-901	-335740940	-gfix_full_req	-«full» or «reserve» required Требуются «full» или «reserve»
-901	-335740941	-gfix usrname req	-User name required. Требуется имя пользователя
-901	-335740942	-gfix_pass req	-Password required. Требуется пароль
-901	-335740943	-gfix subs name	-Subsystem name. Имя подсистемы
-901	-335740945	-gfix sec req	-Number of seconds required. Требуется число или секунды
-901	-335740946	-gfix nval req	-Numeric value between 0 and 32767 inclusive required. Требуется числовое значение между 9 и 32 767, включительно
-901	-335740347	-gfix type shut	-Must specify type of shutdown. Должен быть указан тип останова
-901	-335740948	-gfix retry	-Please retry, specifying an option. Пожалуйста, повторите, указав режим
-901	-335740951	-gfix retry db	-Please retry, giving a database name. Пожалуйста, повторите, задав имя базы данных
-901	-335740991	-gfix exceed max	-Internal block exceeds maximum size. Внутренний блок превышает максимальный размер
-901	-335740992	-gfix_corrupt pool	-Corrupt pool. Разрушен пул
-901	-335740993	-gfix mem exhausted	-Virtual memory exhausted. Исчерпана виртуальная память
-901	-335740994	-gfix bad_pool	-Bad pool id. Неверный идентификатор пула
-901	-335740995	-gfix trn_not_valid	-Transaction state <number> not in valid range. Состояние транзакции <строка> не находится в допустимом диапазоне
-901	-335741012	-gfix unexp eoi	-Unexpected end of input. Неверное завершение ввода
-901	-335741018	-gfix recon fail	-Failed to reconnect to a transaction in database <string>. Ошибки при повторном соединении с транзакцией в базе данных <строка>
-901	-335741036	-gfix trn unknown	-Transaction description item unknown. Неизвестное описание элемента транзакции
-901	-335744038	-gfix mode req	-«read only» or «read write» required. Требуется «только для чтения» или «чтение и запись»
-901	-336068796	-dyn_role_does_not_exist	-SQL role <string> does not exist. Не существует роль SQL <строка>
-901	-336068797	-dyn no grant admin opt	-Dser <string> has no grant admin option on SQL role <string>. Пользователь <строка> не получил от администратора роли SQL <строка>
-901	-336068798	-dyn user not role member	-User <string> is not a member of SQL role <string>. Пользователь <строка> не является участником роли SQL <строка>
-901	-336068799	-dyn delete role failed	-<string> is not the owner of SQL role <string>. <Строка> не является владельцем роли SQL <строка>
-901	-336068800	-dyn grant role to user	-<string> is a SQL role and not a user. <Строка> является ролью SQL, а не пользователем
-901	-336068801	-dyn inv sql role name	-User name <string> could not be used for SQL role. Имя пользователя <строка> не может быть использовано в качестве роли SQL
-901	-336068802	-dyn dup sql role	-SQL role <string> already exists. Роль SQL <строка> уже существует
-901	-336068803	-dyn_kywd_spec for role	-Keyword <string> can not be used as a SQL role name. Ключевое слово <строка> не может быть использовано в качестве имени роли SQL
-901	-336068804	-dyn_roles_not_supported	-SQL roles are not supported in on older versions of the database. A backup and restore of the database is required. Роли SQL не поддерживаются в старых версиях базы данных. Требуется копирование и восстановление базы данных
-901	-336068820	-dyn_zero_len_id	-Zero length identifiers are not allowed. Недопустима нулевая длина идентификатора
-901	-336330753	-gbak unknown switch	-Found unknown switch. Найден неизвестный переключатель
-901	-336330754	-gbak_page size missing	-Page size parameter missing. Отсутствует параметр размера страницы
-901	-336330755	-gbak_page size toobig	-Page size specified (<number>) greater than limit (8192 bytes). Указанный размер страницы (<число>) больше ограничения (8192 байт)
-901	-336330756	-gbak redir_ouput missing	-Redirect location for output is not specified. Не задано перенаправление вывода
-901	-336330757	-gbak_switches_conflict	-Conflicting switches for backup/restore. Конфликт переключателей для копирования/восстановления
-901	-336330758	-gbak_unknown_device	-Device type <string> not known. Тип устройства <строка> не известен
-901	-336330759	-gbak_no_protection	-Protection is not there yet. Защита пока не установлена
-901	-336330760	-gbak_page size not allow ed	-Page size is allowed only on restore or create. Размер страницы нужен только при восстановлении или при создании
-901	-336330761	-gbak multi source dest	-Multiple sources or destinations specified. Указано множество источников или результатов
-901	-336330762	-gbak filename missing	-Requires both input and output filenames. Требуются имена входного и выходного файлов
-901	-336330763	-gbak dup_inout_names	-Input and output have the same name. Disallowed. Вход и выход имеют одинаковые имена. Отвергаются
-901	-336330764	-gbak_inv_page_size	-Expected page size, encountered «<string>». Ожидается размер страницы, появилось «<строка>»
-901	-336330765	-gbak db specified	-REPLACE specified, but the first file <string> is a database. Указано REPLACE, однако первый файл <строка> является базой данных
-901	-336330766	-gbak_db exists	-Database <string> already exists. To replace it, use the-R switch. База данных <строка> уже существует. Для ее замены используйте переключатель -R
-901	-336330767	-gbak_unk_device	-Device type not specified. He задан тип устройства
-901	-336330772	-gbak_blob_jlnfo_f ailed	-Gds_$blob_info failed. Ошибка В Gds $blob info
-901	-336330773	-gbak unk_blob_item	-Do not understand BLOB INFO item <number>. Неизвестный элемент BLOB INFO <число>
-901	-336330774	-gbak get seg failed	-Gds Sget segment failed. Ошибка B Gds $get segment
-901	-336330775	-gbak close blob failed	-Gds $close blob failed. Ошибка B Gds_$close_blob
-901	-336330776	-gbak open blob failed	-Gds $open_blob failed. Ошибка в Gds_$open_blob
-901	-336330777	-gbak_put blr gen id fail ed	-Failed in put blr gen_id. Ошибка B put blr gen id
-901	-336330778	-gbak_unk_type	-Data type <number> not understood. Тип данных <число> не известен
-901	-336330779	-gbak_comp_req_failed	-Gds $compile request failed. Ошибка В Gds $compile request
-901	-336330780	-gbak start_req_failed	-Gds Sstart_request failed. Ошибка В Gds $start request
-901	-336330781	-gbak_rec failed	— gds $receive failed. Ошибка В gds $receive
-901	-336330782	-gbak rel_req_failed	-Gds $ release request failed. Ошибка В Gds Srelease request
-901	-336330783	-gbak db info failed	-gds $database info failed. Ошибка в gds $database info
-901	-336330784	-gbak no db desc	-Expected database description record. Ожидается запись описания базы данных
-901	-336330785	-gbak db create failed	-Failed to create database <string>. Ошибка при создании базы данных <строка>
-901	-336330786	-gbak decomp len error	-RESTORE: decompression length error. RESTORE: ошибка в длине декомпрессии
-901	-336330787	-gbak tbl missing	-Cannot find table <string>. Невозможно найти таблицу <строка>
-901	-336330788	-gbak blob col missing	-Cannot find column for BLOB. Невозможно найти столбец для BLOB
-901	-336330789	-gbak create blob failed	-Gds Screate blob failed. Ошибка В Gds_$create_blob
-901	-336330790	-gbak_put seg failed	-Gds $put segment failed. Ошибка в Gds_$put_segment
-901	-336330791	-gbak rec_len exp	-Expected record length. Ожидается длина записи
-901	-336330792	-gbak inv rec len	-Wrong length record, expected <number> encountered <number>. Неверная длина записи, ожидается <число>, встретилось <число>
-901	-336330793	-gbak_exp_data type	-Expected data attribute. Ожидается атрибут данных
-901	-336330794	-gbak gen id failed	-Failed in store blr_gen id. Ошибка в store blr gen id
-901	-336330795	-gbak unk_rec type	-Do not recognize record type <number>. Не распознан тип записи <число>
-901	-336330796	-gbak inv_bkup_ver	-Expected backup version 1, 2, or 3. Found <number>. Ожидается версия копии 1, 2 или 3. Найдено <число>
-901	-336330797	-gbak missing bkup desc	-Expected backup description record. Ожидается запись описания копии
-901	-336330798	-gbak string trunc	-String truncated. Усечение строки
-901	-336330799	-gbak cant rest_record	-Warning-record could not be restored. Предупреждение — запись не может быть восстановлена
-901	-336330800	-gbak send failed	-Gds $send failed. Ошибка В Gds_$send
-901	-336330801	-gbak no tbl name	-No table name for data. Для данных нет имени таблицы
-901	-336330802	-gbak unexp_eof	-Unexpected end of file on backup file. Конец файла в файле копии
-901	-336330803	-gbak db_format_too old	-Database format <number> is too old to restore to. Формат базы данных <число> слишком старый для восстановления
-901	-336330804	-gbak inv array_dim	-Array dimension for column <string> is invalid. Неверная размерность массива для столбца <строка>
-901	-336330807	-gbak xdr_len expected	-Expected XDR record length. Ожидается длина записи
-901	-336330817	-gbak open bkup_error	-Cannot open backup file <string>. Невозможно открыть файл копии <строка>
-901	-336330818	-gbak open error	-Cannot open status and error output file <string>. Невозможно открыть состояние и ошибка вывода в файл <строка>
-901	-336330934	-gbak missing block fac	-Blocking factor parameter missing. Отсутствует параметр «коэффициент блокирования»
-901	-336330935	-gbak_inv_block_fac	-Expected blocking factor, encountered «<string>». Ожидается коэффициент блокирования, встречено «<строка>»
-901	-336330936	-gbak block_fac_specified	-A blocking factor may not be used in conjunction with device CT. Коэффициент блокирования не может использоваться вместе с устройством CT
-901	-336330940	-gbak missing username	-User name parameter missing. Отсутствует параметр «имя пользователя»
-901	-336330941	-gbak missing_password	-Password parameter missing. Отсутствует параметр «пароль»
-901	-336330952	-gbak missing_skipped_byt es	-Missing parameter for the number of bytes to be skipped. Отсутствует параметр количества пропускаемых байтов
-901	-336330953	-gbak inv skipped_bytes	-Expected number of bytes to be skipped, encountered «<string>». Ожидается количество пропускаемых байтов, встречено «<строка>»
-901	-336330965	-gbak err restore charset	-Bad attribute for RDB$CHARACTER_SETS. Неверный атрибут для RDB$CHARACTER SETS
-901	-336330967	-gbak err restore_collati on	-Bad attribute for RDB$COLLATIONS. Неверный атрибут для RDB$COLLATIONS
-901	-336330972	-gbak read error	-Unexpected I/O error while reading from backup file. Ошибка ввода/вывода при чтении из файла копии
-901	-336330973	-gbak write_error	-Unexpected I/O error while writing to backup file. Ошибка ввода/вывода при записи в файл копии
-901	-336330985	-gbak db in_use	-Could not drop database <string> (database might be in use) . Невозможно удалить базу данных <строка> (возможно база данных используется)
-901	-336330990	-gbak sysmemex	-System memory exhausted. Исчерпана системная память
-901	-336331002	-gbak restore role failed	-Bad attributes for restoring SQL role. Неверный атрибут для восстановления роли SQL
-901	-336331005	-gbak_role_op_missing	-SQL role parameter missing. Отсутствует параметр роли SQL
-901	-336331010	-gbak_page buffers missing	-Page buffers parameter missing. Отсутствует параметр буферов страниц
-901	-336331011	-gbak_page buffers wrong_param	-Expected page buffers, encountered «<string>». Ожидаются буферы страниц, встречено «<строка>»
-901	-336331012	-gbak_page buffers restore	-Page buffers is allowed only on restore or create. Буферы страниц допустимы только при восстановлении или создании
-901	-336331014	-gbak inv size	-Size specification either missing or incorrect for file <string>. Указание размера отсутствует или неверное для файла <строка>
-901	-336331015	-gbak file outof sequence	-File <string> out of sequence. Файл <строка> не задан в последовательности
-901	-336331016	-gbak_join file missing	-Can’t join-one of the files missing. Соединение невозможно — один из файлов отсутствует
-901	-336331017	-gbak stdin not supptd	-Standard input is not supported when using join operation. Стандартный ввод не поддерживается при использовании операции соединения
-901	-336331018	-gbak_stdout not supptd	-Standard output is not supported when using split operation. Стандартный вывод не поддерживается при использовании операции разделения
-901	-336331019	-gbak bkup corrupt	-Backup file <string> might be corrupt. Возможно файл копии <строка> разрушен
-901	-336331020	-gbak unk db_file spec	-Database file specification missing. Отсутствует указание файла базы данных
-901	-336331021	-gbak hdr_write failed	-Can’t write a header record to file <string>. Невозможно записать заголовочную запись в файл <строка>
-901	-336331022	-gbak disk space ex	-Free disk space exhausted. Исчерпано свободное дисковое пространство
-901	-336331023	-gbak size_lt_min	-File size given (<number>) is less than minimum allowed (<number>) . Заданный размер файла (<число>) меньше минимально допустимого (<число>)
-901	-336331025	-gbak svc name missing	-Service name parameter missing. Отсутствует параметр имени сервиса
-901	-336331026	-gbak not ownr	-Cannot restore over current database, must be SYSDBA or owner of the existing database. Невозможно восстановление поверх текущей базы данных, должен быть пользователь SYSDBA или владелец существующей базы данных
-901	-336331031	-gbak mode_req	-«read_only» or «read write» required. Требуется «read_only» или «read write»
-901	-336331033	-gbak just data	-Just data ignore all constraints, etc. Данные игнорируют все ограничения
-901	-336331034	-gbak data only	-Restoring data only ignoring foreign key, unique, not null s other constraints. Восстановление данных только при игнорировании ограничений внешнего ключа, уникального ключа, NOT NULL и других ограничений
-901	-33672398Э	-gsec cant open_db	-Unable to open database. Невозможно открыть базу данных
-901	-336723984	-gsec switches_error	-Error in switch specifications. Ошибка в задании переключателя
-901	-336723985	-gsec no op_spec	-No operation specified. He указана операция
-901	-336723986	-gsec no usr_name	-No user name specified. He задано имя пользователя
-901	-336723987	-gsec err add	-Add record error. Ошибка добавления записи
-901	-336723988	-gsec err modify	-Modify record error. Ошибка изменения записи
-901	-336723989	-gsec err find mod	-Find/modify record error. Ошибка поиска/изменения записи
-901	-336723990	-gsec err rec_not_found	-Record not found for user: <string>. Не найдена запись для пользователя <строка>
-901	-336723991	-gsec err delete	-Delete record error. Ошибка удаления записи
-901	-336723992	-gsec err find_del	-Find/delete record error. Ошибка поиска/удаления записи
-901	-336723996	-gsec err find_disp	-Find/display record error. Ошибка поиска/отображения записи
-901	-336723997	-gsec inv _param	-Invalid parameter, no switch defined. Неверный параметр, не определено переключателей
-901	-336723998	-gsec op specified	-Operation already specified. Операция уже задана
-901	-336723999	-gsec_pw specified	-Password already specified. Пароль уже задан
-901	-336724000	-gsec uid specified	-Uid already specified. UID уже задано
-901	-336724001	-gsec gid specified	-Gid already specified. GID уже задано
-901	-336724002	-gsec_proj_specified	-Project already specified. Проект уже задан
-901	-336724003	-gsec org specified	-Organization already specified. Организация уже задана
-901	-336724004	-gsec fname specified	-First name already specified. Имя уже задано
-901	-336724005	-gsec mname specified	-Middle name already specified. Второе имя уже задано
-901	-336724006	-gsec lname specified	-Last name already specified. Фамилия уже задана
-901	-336724008	-gsec inv switch	-Invalid switch specified. Задан неверный переключатель
-901	-336724009	-gsec amb switch	-ambiguous switch specified. Задан неоднозначный переключатель
-901	-336724010	-gsec no op specified	-No operation specified for parameters. Для параметров не задана операция
-901	-336724011	-gsec_params not allowed	-No parameters allowed for this operation. Параметры недопустимы для этой операции
-901	-336724012	-gsec incompat switch	-Incompatible switches specified. Заданы несовместимые переключатели
-901	-336724044	-gsec inv username	-Invalid user name (maximum 31 bytes allowed). Неверное имя пользователя (допустимо максимум 31 байт)
-901	-336724045	-gsec inv_jpw_length	-Warning-maximum 8 significant bytes of password used. Предупреждение — используется максимум 8 значащих байтов в используемом пароле
-901	-336724046	-gsec_db_specified	-Database already specified. База данных уже задана
-901	-336724047	-gsec db admin specified	-Database administrator name already specified. Имя администратора базы данных уже задано
-901	-336724048	-gsec db admin_pw_specifi ed	-Database administrator password already specified. Пароль администратора базы данных уже задан
-901	-336724049	-gsec sql role specified	-SQL role name already specified. Имя роли SQL уже задано
-901	-336920577	-gstat unknown_switch	-Found unknown switch. Найден неизвестный переключатель
-901	-336920578	-gstat retry	-Please retry, giving a database name. Пожалуйста, повторите, задав имя базы данных
-901	-336920579	-gstat wrong_ods	-Wrong ODS version, expected <number>, encountered <number>. Неверная версия ODS, ожидается <число>,встречено <число>
-901	-336920580	-gstat unexpected eof	-Unexpected end of database file. Конец файла базы данных
-901	-336920605	-gstat open err	-Can’t open database file <string>. Невозможно открыть файл базы данных <строка>
-901	-336920606	-gstat read err	-Can’t read a database page. Невозможно прочесть страницу базы данных
-901	-336920607	-gstat sysmemex	-System memory exhausted. Исчерпана системная память
-902	-335544333	-bug check	-Internal gds software consistency check (<string>). Проверка достоверности внутреннего программного продукта gds (<строка>)
-902	-335544335	-db corrupt	-Database file appears corrupt (<string>). Разрушение файла базы данных (<строка>)
-902	-335544344	-io error	-I/O error for file %.0s»<string>» . Ошибка ввода/вывода для файла «<строка>»
-902	-335544346	-metadata corrupt	-Corrupt system table. Разрушена системная таблица
-902	-335544373	-sys request	-Operating system directive <string> failed. Ошибочная директива операционной системы <строка>
-902	-335544384	-badblk	-Internal error. Внутренняя ошибка
-902	-335544385	-.invpoolcl	-Internal error. Внутренняя ошибка
-902	-335544387	-relbadblk	-Internal error. Внутренняя ошибка
-902	-335544388	-blktoobig	-Block size exceeds implementation restriction. Размер блока превышает ограничение реализации
-902	-335544394	-badodsver	-Incompatible version of on-disk structure. Несовместимая версия для ODS
-902	-335544397	-dirtypage	-Internal error. Внутренняя ошибка
-902	-335544398	-waifortra	-Internal error. Внутренняя ошибка
-902	-335544399	-doubleloc	-Internal error. Внутренняя ошибка
-902	-335544400	-nodnotfnd	-Internal error. Внутренняя ошибка
-902	-335544401	-dupnodfnd	-Internal error. Внутренняя ошибка
-902	-335544402	-locnotmar	-Internal error. Внутренняя ошибка
-902	-335544404	-corrupt	-Database corrupted. База данных разрушена
-902	-335544405	-badpage	-Checksum error on database page <numbe r>. Ошибка контрольной суммы для страницы базы данных <число>
-902	-335544406	-badindex	-Index is broken. Индекс разрушен
-902	-335544409	-trareqmis	-Transaction-request mismatch (synchronization error). Транзакция — несогласованный запрос (ошибка синхронизации)
-902	-335544410	-badhndcnt	-Bad handle count. Ошибочный счетчик дескриптора
-902	-335544411	-wrotpbver	-Wrong version of transaction parameter block. Неверная версия блока параметров транзакции
-902	-335544412	-wroblrver	-Unsupported BLR version (expected <number>, encountered <number>) . Неподдерживаемая версия BLR (ожидается <число>, встречено <число>)
-902	-335544413	-wrodpbver	-Wrong version of database parameter block. Неверная версия блока параметров базы данных
-902	-335544415	-badrelation	-Database corrupted. База данных разрушена
-902	-335544416	-nodetach	-Internal error. Внутренняя ошибка
-902	-335544417	-notremote	-Internal error. Внутренняя ошибка
-902	-335544422	-dbfile	-Internal error. Внутренняя ошибка
-902	-335544423	-orphan	-Internal error. Внутренняя ошибка
-902	-335544432	-lockmanerr	-Lock manager error. Ошибка менеджера блокировок
-902	-335544436	-sqlerr	-SQL error code = <number>. Код ошибки SQL = <число>
-902	-335544448	-bad sec_info	—
-902	-335544449	-invalid sec info	—
-902	-335544470	-buf invalid	-Cache buffer for page <number> invalid. Неверный буфер кэша для страницы <число>
-902	-335544471	-indexnotdefined	-There is no index in table <string> with id <number>. Не существует индексов для таблицы <строка> с идентификатором <число>
-902	-335544472	-login	-Your user name and password are not defined. Ask your database administrator to set up a Firebird login. Не определены ваше имя и пароль. Чтобы установить соединение с Firebird, обратитесь к администратору базы данных
-902	-335544506	-shutinprog	-Database <string> shutdown in progress. Выполняется останов базы данных <строка>
-902	-335544528	-shutdown	-Database <string> shutdown. База данных <строка> остановлена
-902	-335544557	-shutfail	-Database shutdown unsuccessful. Неуспешный останов базы данных
-902	-335544569	-dsql error	-Dynamic SQL Error. Ошибка динамического SQL
-902	-335544653	-psw attach	-Cannot attach to password database. Невозможно соединиться с базой данных пароля
-902	-335544654	-psw start trans	-Cannot start transaction for password database. Невозможно стартовать транзакцию для базы данных пароля
-902	-335544717	-err stack limit	-Stack size insufficient to execute current request. Размер стека недостаточен для выполнения текущего запроса
-902	-335544721	-network error	-Unable to complete network request to host «<string>». Невозможно завершить сетевой запрос на хост «<строка>»
-902	-335544722	-net_connect_err	-Failed to establish а connection. Ошибка при установлении соединения
-902	-335544723	-net connect listen err	-Error while listening for an incoming connection. Ошибка при прослушивании входного соединения
-902	-335544724	-net event connect err	-Failed to establish a secondary connection for event processing. Ошибка при установлении вторичного соединения для обработки события
-902	-335544725	-net event listen err	-Error while listening for an incoming event connection request. Ошибка при прослушивании запроса события соединения
-902	-335544726	-net read err	-Error reading data from the connection. Ошибка чтения данных из соединения
-902	-335544727	-net_write_err	-Error writing data to the connection. Ошибка записи данных в соединение
-902	-335544732	-unsupported network drive	-Access to databases on file servers is not supported. Доступ к базам данных в файловых серверах не поддерживается
-902	-335544733	-io create err	-Error while trying to create file. Ошибка при попытке создания файла
-902	-335544734	-io open err	-Error while trying to open file. Ошибка при попытке открытия файла
-902	-335544735	-io close err	-Error while trying to close file. Ошибка при попытке закрытия файла
-902	-335544736	-io read err	-Error while trying to read from file. Ошибка при попытке чтения из файла
-902	-335544737	-io write err	-Error while trying to write to file. Ошибка при попытке записи в файл
-902	-335544738	-io delete err	-Error while trying to delete file. Ошибка при попытке удаления файла
-902	-335544739	-<io access err	-Error while trying to access file. Ошибка при попытке доступа к файлу
-902	-335544745	-login_same as role name	-Your login <string> is same as one of the SQL role name. Ask your database administrator to set up a valid Firebird login. Ваше регистрационное имя <строка> то же, что и имя роли SQL. Уточните у вашего администратора базы данных допустимое регистрационное имя Firebird
-902	-335544791	-file_in use	-The file <string> is currently in use by another process. Try again later. Файл <строка> в настоящее время используется другим процессом. Попытайтесь позже
-902	-335544795	-unexp spb form	-Unexpected item in service parameter block, expected <string>. Неопределенный элемент в блоке параметров сервиса, ожидается <строка>
-902	-335544809	-extern func dir error	-Function <string> is in <string>, which is not in a permitted directory for external functions. Функция <строка> находится в <стро- ка>, что не является доступным каталогом для внешних функций
-902	-335544819	-io 32bit exceeded err	-File exceeded maximum size of 2GB. Add another database file or use a 64 bit I/O version of Firebird. Файл превысил максимальный размер 2 Гбайт. Добавьте другой файл базы данных или используйте 64-битовую версию Firebird
-902	-335544820	-invalid_savepoint	-Unable to find savepoint with name <string> in transaction context. Невозможно найти точку сохранения с именем <строка> в контексте транзакции
-902	-335544831	-conf access_denied	-Access to <string> «<string>» is denied by server administrator. Доступ к <строка> «<строка>» отвергнут администратором сервера
-904	-335544324	-bad_db_handle	-Invalid database handle (no active connection). Неверный дескриптор базы данных (не активных соединений)
-904	-335544375	-unavailable	-Unavailable database. Недоступная база данных
-904	-335544381	-imp exc	-Implementation limit exceeded. Исчерпан лимит выполнения
-904	-335544386	-nopoolids	-Too many requests. Слишком много запросов
-904	-335544389	-bufexh	-Buffer exhausted. Исчерпан буфер
-904	-335544391	-bufinuse	-Buffer in use. Буфер используется
-904	-335544393	-reqinuse	-Request in use. Запрос используется
-904	-335544424	-no lock mgr	-No lock manager available. Нет доступного менеджераблокировок
-904	-335544430	-virmemexh	-Unable to allocate memory from operating system. Невозможно выделить память в операционной системе
-904	-335544451	-update conflict	-Update conflicts with concurrent update. Изменение конфликтует с текущим изменением
-904	-335544453	-obj in use	-Object <string> is in use. Объект <строка> используется
-904	-335544455	-shadow accessed	-Cannot attach active shadow file. Невозможно соединиться с активным файлом теневой копии
-904	-335544460	-shadow missing	-A file in manual shadow <number> is unavailable. Файл в ручной теневой копии <число> недоступен
-904	-335544661	-index root_page full	-Cannot add index, index root page is full. Невозможно добавить индекс, корневая страница индексов заполнена
-904	-335544676	-sort_mem_err	-Sort error: not enough memory. Ошибка сортировки: недостаточно памяти
-904	-335544683	-req_depth_exceeded	-Request depth exceeded. (Recursive definition?) Превышена глубина запроса (рекурсивное определение?)
-904	-335544758	-sort_rec size_err	-Sort record size of <number> bytes is too big. Размер записи сортировки в <число> байт слишком велик
-904	-335544761	-too_many handles	-Too many open handles to database. Слишком много открытых дескрипторов базы данных
-904	-335544792	-service att_err	-Cannot attach to services manager. Невозможно подключиться к менеджеру сервисов
-904	-335544799	-svc name missing	-The service name was not specified. Не указано имя сервиса
-904	-335544813	-optimizer between err	-Dnsupported field type specified in BETWEEN predicate. Указан неподдерживаемый тип поля в предикате BETWEEN
-904	-335544827	-exec sql invalid arg	-Invalid argument in EXECUTE STATEMENT- cannot convert to string. Неверный аргумент в EXECUTE STATEMENT — невозможно конвертировать в строку
-904	-335544828	-exec sql invalid req	-Wrong request type in EXECUTE STATEMENT ‘<stzing>’. Ошибочный тип запроса в EXECUTE STATEMENT ‘<строка>’
-904	-335544829	-exec sql invalid var	-Variable type (position <number>) in EXECUTE STATEMENT ‘<string>’ INTO does not match returned column type. Тип переменной (позиция <число>) В EXECUTE STATEMENT ‘<строка>’ INTO не соответствует возвращаемому типу столбца.
-904	-335544830	-exec sql max call exceed ed	-Too many recursion levels of EXECUTE STATEMENT. Слишком много уровней рекурсии В EXECUTE STATEMENT
-906	-335544744	-max att exceeded	-Maximum user count exceeded. Contact your database administrator. Превышен максимум счетчика пользователей
-909	-335544667	-drdb completed with errs	-Drop database completed with errors. Удаление базы данных завершилось с ошибками
-911	-335544459	-rec in limbo	-Record from transaction <number> is stuck in limbo. Запись транзакции <число> становится зависшей
-913	-335544336	-deadlock	-Deadlock. Взаимная блокировка
-922	-335544323	-bad db format	-File <strinij> is not a valid database. Файл <строка> не является допустимой базой данных
-923	-335544421	-connect reject	-Connection rejected by remote interface. Соединение отменено удаленным интерфейсом
-923	-335544461	-cant_validate	-Secondary server attachments cannot validate databases. Вторичные подключения к серверу не могут проверять базы данных
-923	-335544464	-cant start logging	-Secondary server attachments cannot start logging. Вторичные подключения к серверу не могут запускать соединения
-924	-335544325	-bad dpb content	-Bad parameters on attach or create database. Неверные параметры при подключении или создании базы данных
-924	-335544441	-bad detach	-Database detach completed with errors. Отключение от базы данных завершилось с ошибками
-924	-335544648	-conn_lost	-Connection lost to pipe server. Потеря соединения с каналом сервера
-926	-335544447	-no rollback	-No rollback performed. Не выполнен откат транзакции
-999	-335544689	-ib error	-Firebird error. Ошибка Firebird

Приложение 11. Зарезервированные слова

В табл. П11.1 содержатся ключевые слова, которые зарезервированы в Firebird. Некоторые имеют специальные отметки:

* KEYWORD (con.) отмечает слова, которые зарезервированы в их специфическом контексте. Например, слово UPDATING является ключевым словом в PSQL и будет недоступно в качестве имени переменной или аргумента;

* [KEYWORD] отмечает слова, которые в настоящий момент не являются зарезервированными, но предполагается сделать их таковыми в будущей реализации или для совместимости с InterBase;

* /* KEYWORD */ отмечает слова, которые были зарезервированными в Firebird 1.0.x, но были освобождены в Firebird 1.5.

Таблица П11.1. Зарезервированные слова Firebird

[ ABS]	ACTION	ACTIVE
ADD	ADMIN	AFTER
ALL	ALTER	AND
ANY	ARE	AS
ASC	ASCENDING	AT
AUTO	AUTODDL	AVG
BASED	BASENAME	BASE_NAME
BEFORE	BEGIN	BETWEEN
BIGINT	BLOB	BLOBEDIT
[BOOLEAN]	[BOTH]	/* BREAK */
BUFFER	BY	CACHE
CASCADE	CASE	CAST
CHAR	CHARACTER	[CHAR_LENGTH]
[CHARACTER_LENGTH]	CHECK	CHECK_POINT_LEN
CHECK_POINT_LENGTH	CLOSE	COALESCE (con.)
COLLATE	COLLATION	COLUMN
COMMIT	COMMITTED	COMPILETIME
COMPUTED	CONDITIONAL	CONNECT
CONSTRAINT	CONTAINING	CONTINUE
COUNT	CREATE	CSTRING
CURRENT	CURRENT_CONNECTION	CURRENT_DATE
CURRENT_ROLE	CURRENT_TIME	CURRENT_TIMESTAMP
CURRENT_TRANSACTION	CURRENT_USER	DATABASE
DATE	DAY	DB_KEY
DEBUG	DEC	DECIMAL
DECLARE	DEFAULT	[DEFERRED]
DELETE	DELETING (con.)	DESC
DESCENDING	DESCRIBE	/* DESCRIPTOR */
DISCONNECT	DISPLAY	DISTINCT
DO	DOMAIN	DOUBLE
DROP	ECHO	EDIT
ELSE	END	ENTRY_POINT
ESCAPE	EVENT	EXCEPTION
EXECUTE	EXISTS	EXIT
EXTERN	EXTERNAL	EXTRACT
[FALSE]	FETCH	FILE
FILTER	/* FIRST */	FLOAT
FOR	FOREIGN	FOUND
FREE_IT	FROM	FULL
FUNCTION	GDSCODE	GENERATOR
GEN_ID	[GLOBAL]	GOTO
GRANT	GROUP	GROUP_COMMIT_WAIT
GROUP_COMMIT_WAIT_TIME	HAVING	HEADING
HELP	HOUR	IF
/* IIF */	IMMEDIATE	IN
INACTIVE	INDEX	INDICATOR
INIT	INNER	INPUT
INPUT TYPE	INSERT	INSERTING (con.)
INT	INTEGER	INTO
IS	ISOLATION	ISQL
JOIN	KEY	LAST (con.)
LC_MESSAGES	LC TYPE	[LEADING]
LEAVE (con.)	LEFT	LENGTH
LEV	LEVEL	LIKE
LOCK (con.)	LOGFILE	LOG_BUFFER_SIZE
LOG_BUF_SIZE	LONG	MANUAL
MAX	MAXIMUM	MAXIMUM_SEGMENT
MAX_SEGMENT	MERGE	MESSAGE
MIN	MINIMUM	MINUTE
MODULE_NAME	MONTH	NAMES
NATIONAL	NATURAL	NCHAR
NO	NOAUTO	NOT
NULL	NULLIF (con.)	NULLS (con.)
NUM_LOG_BUFS	NUM_LOG_BUFFERS	NUMERIC
[OCTET_LENGTH]	OF	ON
ONLY	OPEN	OPTION
OR	ORDER	OUTER
OUTPUT	OUTPUT_TYPE	OVERFLOW
PAGE	PAGELENGTH	PAGES
PAGE_SIZE	PARAMETER	PASSWORD
[PERCENT]	PLAN	POSITION
POST_EVENT	PRECISION	PREPARE
[PRESERVE]	PRIMARY	PRIVILEGES
PROCEDURE	PUBLIC	QUIT
RAW_PARTITIONS	RDB$DB_KEY	READ
REAL	RECORD_VERSION	RECREATE
REFERENCES	RELEASE	RESERV
RESERVING	RESTRICT	RETAIN
RETURN	RETURNING/ALUES	RETURNS
REVOKE	RIGHT	ROLE
ROLLBACK	ROW_COUNT	[ROWS]
RUNTIME	SAVEPOINT	SCHEMA
SECOND	SELECT	SET
SHADOW	SHARED	SHELL
SHOW	SINGULAR	SIZE
/* SKIP */	SMALLINT	SNAPSHOT
SOME	SORT	SQL
SQLCODE	SQLERROR	SQLWARNING
STABILITY	STARTING	STARTS
STATEMENT (con.)	STATIC	STATISTICS
SUB_TYPE	/* SUBSTRING */	SUM
SUSPEND	TABLE	[TEMPORARY]
TERM	TERMINATOR	THEN
[TIES]	TIME	TIMESTAMP
TO	[TRAILING]	TRANSACTION
TRANSLATE	TRANSLATION	TRIGGER
[TRIM]	[TRUE]	TYPE
UNCOMMITTED	UNION	UNIQUE
[UNKNOWN]	UPDATE	UPDATING (con.)
UPPER	USER	USING (con.)
VALUE	VALUES	VARCHAR
VARIABLE	VARYING	VERSION
VIEW	WAIT	WEEKDAY
WHEN	WHENEVER	WHERE
WHILE	WITH	WORK
WRITE	YEAR	YEARDAY

Приложение 12. Литература и источники

Firebird содержит огромное количество помощников, испытателей, документации, программного обеспечения, новостей и других ресурсов для помощи вам как разработчику или администратору Firebird. Здесь представлен список некоторых из наиболее известных ресурсов, однако он не является исчерпывающим — новые ресурсы появляются каждый день!

Список Web-сайтов

Сайты проекта Firebird

http://sourceforge.net/projects/firebird является сайтом разработчиков, где вы можете получить доступ к дереву CVS, к исходным и двоичным кодам комплекта поставки и просмотреть список выявленных ошибок.

http://www.firebirdsql.org, алиас http://firebird.sourceforge.net. Здесь вы можете найти информацию и новости проекта. Через этот сайт можно получить доступ ко всем двоичным кодам Firebird, к страницам «как сделать», FAQ (часто задаваемым вопросам), форумам и конференциям.

http://www.firebirdsql.org/index.php?op=ffoundation предоставляет информацию о FirebirdSQL Foundation Inc., некоммерческой группе, которая создала фонд для грантов проекта.

Web-сайты ресурсов

http://www.ibase.ru содержит огромное количество информации по InterBase и Firebird на русском языке: статьи, FAQ, файлы, форум, списки рассылки новостей и др.

http://www.ibphoenix.com является центром информации и новостей для пользователей, разрабатывающих приложения для Firebird или InterBase. Он имеет базу знаний, множество авторитетных статей, контакты с коммерческой поддержкой и консалтингом, ссылки на инструменты и проекты, сервисы подписки на компакт-диски.

http://www.cvalde.net является сайтом гуру Claudio Valderrama, «Неофициальным сайтом InterBase», ссылающимся на сайт InterBase и связанный с многими другими сайтами, где люди делают интересные вещи с Firebird и инструментами разработки. Этот сайт содержит эклектическое собрание статей, различное программное обеспечение, ссылки на новости и многое другое.

http://www.volny.cz/ipi-enosilis- сайт Ivan Prenosil содержит интересные статьи Ивана и инструменты, написанные и поддерживаемые гуру Firebird.

http://www.interbase-world.com полон новостей, интервью и практических статей на русском и английском языках о Firebird и InterBase. Он содержит ссылки на множество других сайтов сообществ Firebird на русском языке и многих иных сайтов.

http://www.ibphoenix.cz- сайт ресурсов для чешских пользователей Firebird и InterBase, поддерживается Pavel Cisar, автором первой чешской книги по Firebird и InterBase. Сайт содержит ссылки, загрузку и консультацию.

http://firebird-fr.eu.orgis поддерживается Philippe Makowski во Франции. Включает ресурсы, статьи и новости.

http://www.comunidade-firebird.org- международный сайт (на португальском языке), поддерживаемый разработчиками и членами Communidade Firebird Lingua Portuguese. Он содержит загрузку, ссылки, сервисы, статьи и работы.

http://www.firebase.com.br/fb является бразильским сайтом на португальском языке, поддерживается Carlos Cantu. Этот сайт содержит новости, статьи, обучающие программы и загрузку программного обеспечения.

http://tech.firebird.gr.jp является домашней страницей Ассоциации пользователей Firebird Японии. Этот сайт предоставляет новости, статьи, ссылки и загрузку.

http://www.fingerbird.de- общедоступный сайт, содержащий ссылки на сайты Firebird, статьи, загрузку, ресурсы и многое другое.

Форумы Firebird

Техническая поддержка: firebird-support@yahoogroups.com. Это основной форум поддержки разработчиков баз данных и приложений. В нем можно задавать вопросы по поводу SQL, инсталляции, конфигурирования, проектирования и маленьких хитростей. В нем можно перейти к вопросам относительно драйверов и сред разработки приложений — для этого существуют отдельные форумы. Также есть ветка для сообщений о предполагаемых ошибках для предварительного обсуждения. Присоединяйтесь к http://groups.yahoo.com/community/firebird-support.

Центральная лаборатория разработчиков: firebird-devel@lists.sourceforge.net. Это список для разработчиков и тестеров. Обычно участники бывают рады помочь в создании вашего исходного кода, однако вам следует провести поиск, чтобы найти «основной» для вас список. Поддержка вопросов и «шумов» там производится вне тем. Приветствуется обсуждение ошибок, вам предоставляется прекрасное описание ошибок с указанием подробностей о версии Firebird, операционной системе, оборудовании и предоставляется система отслеживания ошибок (Bug Tracker) на сайте проекта, если ваша ошибка еще неизвестна. Присоединяйтесь к https://lists.sourceforge.net /lists/listinfo/firebird-devel.

Лаборатория контроля качества тестеров: firebird-test@Iists.sourceforge.net. Это форум для тестеров. Тестеры и проектировщики тестов приглашаются для присоединения к этой группе. Это не повод для обсуждения каких-либо вопросов. Присоединяйтесь к https://lists.sourceforge.net/lists/ listinfo/firebird- test.

Java: firebird-java@yahoogroups.com. Это форум разработчиков и поддержка пользователей драйверов JDBC/JCA (см. приложение 3). Там также есть ветка для сообщений о предполагаемых ошибках в драйверах Java. Присоединяйтесь к этой группе http://groups.yahoo.com/community/firebird-java.

и InterServer не поддерживаются и

! ! !

ПРИМЕЧАНИЕ. Продукты Borland InterClient не разрабатываются для и в Firebird вовсе.

. ! .

Проект драйвера Firebird ODBC-JDBC: firebird-odbc-devel@Iists.sourceforge.net. Это форум разработчиков, тестеров и пользователей драйвера Firebird ODBC-JDBC (см. приложение 3). Обратите внимание, что драйверы ODBC сторонних разработчиков не поддерживаются в этом списке — подробности см. на Web-сайтах владельцев. Присоединяйтесь к списку Firebird ODBC на https://lists.sourceforge.net /lists/listinfo/firebird-odbc-devel.

.NET Provider: firebird-net-provider@lists.sourceforge.net. Это форум разработчиков и пользователей проекта интерфейса Firebird .NET Provider (см. приложение 3). Присоединяйтесь к форуму на https://lists.sourceforge.net/lists/listinfo/firebird-net- provider.

PHP: firebird-PHP@yahoogroups.com. Это форум поддержки разработчиков, создающих приложения Firebird в PHP (см. приложение 3). Присоединяйтесь: http://groups.yahoo.com/community/firebird-php.

Visual Basic: firebird-vb@yahoogroups.com. Это форум поддержки разработчиков, создающих клиентские приложения на Visual Basic. Присоединяйтесь: http:// groups.yahoo.com/community/firebird-vb.

Конвертирование из других СУБД: ib-conversions@yahoogroups.com. Это место, где вы получите советы и рекомендации по конвертированию баз данных в Firebird. Общие вопросы не приветствуются — обратитесь к firebird-support. Присоединяйтесь к http://groups.yahoo.com/community/ib-conversions.

Архитектура и проектирование ядра СУБД: firebird-architect@yahoogroups.com. Здесь обычно околачиваются гуру по разработке ядра, обсуждаются вопросы и планы по улучшению ядра Firebird и его интерфейсов. Приглашаются участники и наблюдатели, однако не разрешены никакие вопросы по поддержке. Обсуждения обычно весьма изысканные. Присоединяйтесь на http://groups.yahoo.com/community /firebird-architect.

Инструменты: firebird-tooIs@yahoogroups.com. Это форум разработчиков инструментов и плагинов для Firebird. Здесь регулярно появляются объявления, а разработчики инструментов обычно доступны, чтобы направить вас в правильную ветку для получения помощи. Присоединяйтесь на http://groups.yahoo.com/community /firebird-tools. Относительно выбора доступных инструментов см. приложение 5.

Общие обсуждения сообщества: firebird-general@yahoogroups.com. Недопустимы никакие вопросы поддержки, а только вещи, тем или иным образом связанные с Firebird. Диапазон тем простирается от логотипов до мягких игрушек, обсуждений распространения, интересных ссылок на онлайновую прессу Firebird.

Документация: firebird-docs@lists.sourceforge.net. Это также не для сторонних наблюдателей — форум для людей, работающих с документацией, или для тех, кто хочет начать работать. Вопросы поддержки также не приветствуются. Если у вас есть желание включиться в этот проект XML, присоединяйтесь на https://lists.sourceforge.net/lists/listinfo/firebird-docs.

Web-сайт: firebird-Website@lists.sourceforge.net. Здесь нет поддержки ваших проектов приложений для Web. Это еще одно место не для сторонних наблюдателей — форум для людей, работающих с Web-сайтом Firebird, или для тех, кто хочет оказать помощь.

Интерфейс группы новостей: все эти списки являются зеркальными для сервера новостей на news://news.atkin.com. Любой может читать трафик списка через этот интерфейс, но вы должны подписаться на список сообщества, чтобы посылать сообщения.

Как стать разработчиком Firebird

У проекта Firebird постоянно открыты двери для хороших программистов C++, кто хочет сделать вклад в проектирование и разработку. Люди становятся участниками не с позволения, а по делам. Первое, что нужно сделать, — получить от SourceForge «метку», а затем присоединиться к спискам firebird-devel и firebird-architect (подробности см. в предыдущем разделе). Найдите существующий или новый проект, который вас интересует, обсудите его и представьте код.

Проект постоянно заинтересован в предложениях серьезных проектировщиков и тестеров.

FirebirdSQL Foundation имеет фонд, из которого могут быть выделены средства, чтобы помочь разработчикам внедрить важную функциональность в Firebird.

Глоссарий

Термин	Определение
fdb или FDB	По соглашению это расширение используется для первичного файла базы данных Firebird. Это не более чем соглашение: Firebird работает с любыми расширениями файлов или вовсе без них
gdb или GDB	По соглашению это расширение файла традиционно используется для баз данных InterBase. Однако файл базы данных Firebird может иметь любое расширение или вовсе не иметь его. Многие разработчики Firebird вместо него используют fdb, чтобы отличить базы данных Firebird от баз данных InterBase или как часть решения проблемы с «обеспечением безопасности», введенным корпорацией Microsoft в ее операционных системах Windows ME и XP, используемых для файлов, имеющих расширение gdb.Почему «GDB»? Это продукт с именем компании, которая создала первоначальную версию InterBase — Groton Database Systems
ADO	Аббревиатура от Active Data Objects — интерфейс высокого уровня приложение-данные, введенный Microsoft в 1996 году. Более ранние версии могли получать доступ только к реляционным базам данных с фиксированными столбцами и типами данных, однако более поздние версии могут соединяться и с другими моделями СУБД, файловыми системами, файлами данных, сообщениями электронной почты, иерархическими структурами и гетерогенными структурами данных
aggregate (function) агрегат (функция)	Функция, которая возвращает результат, полученный в виде обобщения (агрегирования) значений из набора строк, которые сгруппированы некоторым образом с использованием синтаксиса оператора SQL.Например, внутренняя функция SUMO оперирует с непустыми числовыми столбцами и возвращает результат в виде суммы значений всех столбцов для строк, выделенных в предложениях WHERE и ORDER BY. Вывод, являющийся объединением предложения WHERE, возвращает одну выходную строку, в то время как объединение в предложении GROUP BY потенциально возвращает множество строк
alerter (events) обработчик событий	Термин, придуманный для названия клиентской подпрограммы или класса, которые способны «прослушивать» заданные в базе данных события (EVENT), сгенерированные в триггере или хранимой процедуре, выполняемых на сервере
ALICE	Внутреннее имя для кода утилиты gfix — искажение слов «all else» (все остальное)
alternative key (alternate key) альтернативный ключ	Термин, используемый для уникального ключа, который не является первичным ключом. Уникальный ключ создается при применении ограничения UNIQUE К столбцу или группе столбцов. Внешний ключ в форме отношения ссылочной целостности может указывать в его предложении REFERENCES на альтернативный ключ
API	Аббревиатура для Application Programming Interface (Интерфейс прикладного программирования). API предоставляет множество формальных структур, через которые приложения могут связываться с функциями другого программного обеспечения. API Firebird предоставляет подобный интерфейс к клиентской библиотеке, скомпилированной специально для каждой поддерживаемой платформы. Структуры в API Firebird являются структурами языка С, они созданы, чтобы быть переносимыми на любой язык программирования. Трансляция может выполняться для Java, Pascal, Perl различных уровней, PHP 4/5, Python и др.
argument аргумент	Переменная заранее описанного типа и размера, которая передается функции или хранимой процедуре для выполнения с ней действий. Хранимая процедура может быть разработана для использования как входных аргументов, так и возвращаемых выходных аргументов. Для возвращаемых значений функций (как внутренних, так и определенных пользователем) термин результат используется чаще, чем аргумент.Термины параметр и аргумент часто используются как взаимозаменяемые в отношении хранимых процедур благодаря приспособлению фирмой Borland термина параметр в классах доступа к данным Delphi для именования свойств, которые назначает аргументам хранимая процедура
array slice срез массива	Непрерывный диапазон элементов массива Firebird называется срезом массива. Срез массива может состоять из любого количества смежных блоков данных из массива, от одного элемента размерности до максимального количества элементов всех определенных размерностей
atomicity атомарность	В контексте транзакции атомарность ссылается на вид механизма транзакции, который является «упаковкой» для группы изменений строк в одной или более таблицах для получения одной единицы работы, которая будет либо полностью подтверждена, либо полностью отменена. В контексте ключа, ключ является атомарным, если его значение не имеет связи с прикладными данными
AutoCommit	Когда изменение отправляется в базу данных, оно не станет постоянным, пока не будет подтверждена транзакция в клиентском приложении, в рамках которой отправлялись изменения. Если же клиент выполняет откат транзакции, а не ее подтверждение, то отправленные изменения будут отменены.Некоторые клиентские инструменты, драйверы или библиотеки компонентов предоставляют механизм, при котором отправка любых изменений любой таблицы следом вызывает подтверждение транзакции без каких-либо усилий со стороны пользователя. Этот механизм обычно называют AutoCommit или похожим термином. Он не является механизмом Firebird — Firebird никогда не подтверждает транзакции, стартованные в клиенте
backup/restore (Firebird style) копирование/ восстановление(в стиле Firebird)	Копирование (backup) является внешним процессом, инициированным пользователем- обычно SYSDBA- для помещения базы данных в набор сжатых дисковых структур, включающих метаданные и данные, которые разделяются при хранении. Восстановление (restore) является другим внешним процессом — также инициируемым пользователем, — который полностью реконструирует исходную базу данных из ее сохраняемых элементов. Процесс копирования также может выполнять сборку мусора в базе данных в процессе ее чтения; восстановленная база данных полностью свободна от «мусора». См. также gbak
BDE	Аббревиатура для Borland Database Engine (Движок базы данных Borland). Первоначально создан как ядро базы данных Paradox, он был расширен для того, чтобы обеспечить промежуточный уровень доступа между различными реляционными базами данных и инструментами приложений Borland для платформ Microsoft DOS и Windows. Правила, заданные производителем, применимые к каждой реляционной СУБД, инкапсулированы в наборе драйверов, называемых SQLLinks. Драйверы SQLLinks имеют особенности, изменяемые от версии к версии.С 2000 года, когда Borland создал код базы данных, на котором был разработан Firebird 1.0, BDE был признан устаревшим в пользу более современных технологий драйверов. Последняя известная версия BDE (5.2) поставляется вместе с Borland Delphi 6 и выше. Драйвер InterBase в этой поставке только частично поддерживает Firebird
binary tree двоичное дерево	Логическая структура дерева, в которой узлы могут содержать максимум две ветви. Индексы Firebird созданы на базе структур b-tree, которые в отличие от двоичных деревьев на уровне ветви могут содержать много элементов
BLOB	Акроним для Binary Large Object (большой двоичный объект). Это элемент данных неограниченного размера в любом формате, который можно переслать в потоке в базу данных байт за байтом и сохранить без каких-либо изменений формы. Firebird допускает BLOB различных типов, классифицированных на основании подтипов. Прародитель Firebird, InterBase был первой реляционной базой данных, поддерживающей BLOB. См. также CLOB
BLOB control structureуправляющая структура BLOB	Структура языка С, объявленная в модуле UDF в виде typedef, с помощью которой UDF BLOB получает доступ к BLOB. UDF BLOB не может ссылаться на фактические данные BLOB, а использует вместо этого указатель на управляющую структуру BLOB
BLOB filter фильтр BLOB	Специализированная UDF, которая преобразует данные BLOB из одного подтипа в другой. Firebird включает множество внутренних фильтров BLOB, которые он использует в процессе сохранения и поиска метаданных. Один из внутренних фильтров конвертирует текстовые данные между подтипом 0 (никакой) и подтипом 1 (текст, иногда называемый «Memo»)
BLR	Аббревиатура Binary Language Representation (двоичное представление языка), внутреннего реляционного языка с двоичными нотациями, который является надмножеством «читаемых человеком» языков и может быть использован в Firebird, конкретно в SQL и GDML. Интерфейс DSQL в Firebird для сервера транслирует запросы в BLR. Версии BLR скомпилированных триггеров, хранимых процедур, ограничений CHECK, значений по умолчанию и просмотров хранятся в полях BLOB. Некоторые клиентские инструменты — например, IB_SQL и инструмент командной строки isql — имеют средства просмотра этих кодов BLR. В isql выполните команду SET BLOB ALL, а затем выполните операторы SELECT для получения соответствующих полей из системных таблиц
buffer буфер	Блок памяти для хранения копий страниц, прочитанных из базы данных. Термин «буфер» является синонимом термина «страничный кэш»
BURP	Внутреннее имя для кода gbak — акроним для Backup [and] Restore Program (программа копирования и восстановления)
cache кэш	Когда страница читается с диска, она копируется в блок памяти, который имеет название кэш базы данных или просто кэш. Кэш состоит из блоков памяти, каждый размером в страницу базы данных, определяемый параметром PAGE_SIZE, объявляемым при создании базы данных.Размер кэша можно настроить, задав количество страниц. Следовательно, для вычисления размера кэша умножьте PAGE?SIZE на количество страниц кэша
cardinality (of a set) мощность (набора)	Количество строк в физическом или заданном наборе. Кардинальность строки указывает ее положение в наборе строк
case-insensitive index индекс, не чувствительный к регистру	Индекс, используемый в сортировке, когда буквы в нижнем регистре трактуются так, как если бы они были в верхнем регистре. Firebird 1.0 не поддерживает нечувствительные к регистру индексы. Небольшое количество нечувствительных к регистру порядков сортировки появилось в Firebird 1.5
cascading integrity constraintsкаскадные ограничения целостности	Firebird предоставляет возможность задать особые виды поведения и ограничения в ответ на запросы на изменение или удаление строк в таблицах, на которые есть ссылки в предложении REFERENCES ограничения FOREIGN KEY. Ключевое слово CASCADE приводит к тому, что изменения, выполненные для «родительской» строки, будут распространяться на строки в таблицах, имеющих зависимости FOREIGN KEY. Например, ON DELETE CASCADE приведет к удалению всех зависимых строк при удалении родительской строки
castingпреобразование	Механизм для конвертирования выходных значений или значений переменных из одного типа данных в другой в выражениях. SQL Firebird предоставляет функцию CASTO для использования как в выражениях динамического SQL (DSQL), так и процедурного SQL (PSQL)
character set	В основном два надмножества печатаемых образов символов и управляющих последовательностей на сегодняшний день используется в программных окружениях: ASCII и UNICODE. Символы ASCII, представленные в одном байте, имеют 256 вариантов, в то время как символы UNICODE, представляемые 2, 3 и 4 байтами, могут предоставить десятки тысяч возможностей. Поскольку для баз данных требуется исключить непомерно высокие накладные расходы, чтобы сделать доступными все возможные печатаемые и управляющие символы, используемые при программировании в любой точке мира, это надмножество разделено на кодовые страницы, также называемые кодовыми таблицами. Каждая кодовая страница определяет подмножество требуемых символов для конкретного языка или семейства языков, представляя образ каждого символа в виде числа. Эти образы и управляющие последовательности в каждой кодовой странице называются наборами символов. Образ символа может отображаться в различные числа в различных наборах символов. Firebird поддерживает для базы данных набор символов по умолчанию и явное определение набора символов для каждого столбца, имеющего тип данных CHARACTER, VARYING CHARACTER и BLOB SUB_TYPE 1 (текстовый BLOB). Если для базы данных не определен никакой набор символов, ее набор символов по умолчанию будет NONE, в результате чего все символьные данные будут сохраняться точно так, как они представлены без попыток конвертирования символов (выполнения транслитерации) для любого конкретного набора символов
Classic architecture Классическая архитектура	Начальная модель InterBase, когда для каждого клиентского соединения стартует отдельный серверный процесс. Эта архитектура предшествовала модели Суперсервера, при которой для клиентов создаются потоки в рамках единого серверного процесса. Варианты обеих моделей архитектуры доступны для множества платформ операционной системы
CLOB	Акроним для Character Large OBject (большой символьный объект). Этот термин появился из более раннего использования, когда другие СУБД копировали поддерживаемое в Firebird хранение больших объектов в базе данных. CLOB является эквивалентом BLOB SUB_TYPE 1 (TEXT). См. также BLOB
coercing data types приведение типов данных	В структурах XSQLDA API Firebird преобразование элемента данных из одного типа SQL в другой называется приведением типов данных
collation order порядок сортировки	Определяет, как операция сортировки упорядочивает символьные столбцы в выходных наборах, задавая пары символов в нижнем и верхнем регистрах для функции UPPERO, а также как символы в символьных столбцах сравниваются при поиске. Порядок сортировки применим для конкретного набора символов. Если для набора символов доступно множество порядков сортировки, то один из порядков сортировки будет трактоваться как порядок по умолчанию. По соглашению порядок сортировки по умолчанию имеет то же имя, что и набор символов
column столбец	В базах данных SQL данные хранятся в структурах, которые могут быть выбраны в виде таблиц, или более корректно — наборов. Набор состоит из одной или более строк, каждая из которых идентична в горизонтальном порядке для элементов данных, имеющих разные типы. Один отдельный элемент данных, рассматриваемый вертикально по всей длине набора, называется столбцом. Разработчики приложений часто называют столбцы полями (когда речь идет об одной записи или о структуре таблицы)
commitподтверждение (транзакции)	Когда приложения посылают изменения, действующие на строки в таблицах базы данных, то создаются новые версии таких строк во временных блоках хранения. Хотя работа видна в той транзакции, в которой она была выполнена, она не видима другим пользователям базы данных. Клиентская программа должна сообщитьсерверу о подтверждении (commit) работы, чтобы сделать эти изменения постоянными. Если транзакция не подтверждается, для нее должен быть выполнен откат (rollback), чтобы отменить эту работу
CommitRetaining	Установка для транзакции, которая реализует атрибут транзакции COMMIT WITH RETAIN (подтверждение с сохранением контекста). Также называется мягким подтверждением. При этом атрибуте контекст транзакции сохраняется активным на сервере, пока клиентское приложение окончательно не вызовет COMMIT (жесткое подтверждение) и не позволит процессу управления инвентарными страницами транзакций передать старые версии сборке мусора. Широкое использование в приложениях CommitRetaining является общей причиной ухудшения производительности. См. также Oldest Interesting Transaction (OIT)
concurrency параллельность, одновременность, конкурентность	Термин используется для названия ситуации, когда множество пользователей одновременно имеют доступ к одним и тем же данным. Этот термин также широко используется в документации и списках поддержки для ссылок на конкретный набор атрибутов, применимых к транзакции: уровень изоляции, стратегия блокировок и др. Например, кто-то может вас спросить: «Какие у вас установки конкурентности?». Еще более специфическим образом этот термин иногда используется как синоним уровня изоляции SNAPSHOT
constraint ограничение	Firebird предоставляет множество возможностей для определения формальных правил, применимых к данным. Такие формальные правила называются ограничениями. Например, PRIMARY KEY является ограничением, которое отмечает столбец или группу столбцов как общий в базе данных указатель для всех других столбцов в строке. Ограничение CHECK устанавливает одно или более правил, ограничивающих те значения, которые может принимать столбец
contention конфликт	Когда две транзакции пытаются одновременно изменить в таблице одну и ту же строку, то говорят о конфликте, а транзакции являются конфликтными
correlated subqueryкоррелированный подзапрос	Спецификация запроса может определять выходные столбцы, которые получаются из выражений. Подзапрос — это выражение специального вида, которое возвращает одно значение, являющееся результатом выполнения оператора SELECT. В коррелированном подзапросе предложение WHERE содержит один или более ключей поиска, которые связаны отношением со столбцами из главного запроса
crash крах	Жаргонный термин для ненормального завершения сервера или клиентского приложения
crash recovery восстановление после краха	Процессы или процедуры, которые реализуют восстановление сервера и/или клиентского приложения после аварийного завершения сервера или клиентского приложения (или обоих) в работоспособное состояние
CVS	Аббревиатура для Concurrent Versions System (система одновременных версий) — программы с открытыми кодами, которая позволяет разработчикам сохранять различные версии исходного кода разработки. CVS широко используется в проектах с открытыми кодами, включая проект Firebird
cyclic linksциклические ссылки	В контексте базы данных это зависимости между таблицами, когда внешний ключ одной таблицы (TableA) ссылается на уникальный ключ другой таблицы (TableB), которая содержит внешний ключ, ссылающийся непосредственно или через другую таблицу на уникальный ключ таблицы TableA
database база данных	В самом широком смысле термин «база данных» применяется к любой постоянной файловой структуре, которая сохраняет данные в некотором формате, позволяющем их отыскивать и манипулировать ими в приложениях
DB_KEY	См. RDB$DB_KEY
DDL	Аббревиатура от Data Definition Language (язык определения данных), подмножества SQL, которое используется для определения и управления структурами объектов данных. Любой оператор SQL, начинающийся с ключевого слова CREATE, ALTER, RECREATE, CREATE OR REPLACE или DROP, является оператором DDL. В Firebird некоторые операторы DDL начинаются с ключевого слова DECLARE, хотя не все операторы DECLARE относятся к DDL
deadlockвзаимная блокировка	Когда две транзакции конкурируют в изменении одной и той же версии строки, про них говорят, что они находятся в состоянии взаимной блокировки, то есть когда одна транзакция (T1), имеющая блок на строку А, запрашивает изменение строки В, которая заблокирована другой транзакцией (T2), и транзакция T2 собирается изменять строку А. Обычно подлинные взаимные блокировки случаются очень редко, поскольку сервер может определить большинство таких блокировок и самостоятельно разрешить их без выдачи исключения блокировки. К сожалению, сервер Firebird объединяет все сообщения о конфликтах блокировки в один код сообщения, которое говорит о «взаимной блокировке», независимо от фактического источника конфликта. Код клиентского приложения должен разрешить конфликт блокировки, выполняя откат одной транзакции, чтобы дать возможность другой транзакции подтвердить ее работу
degree (of a set) степень(набора)	Количество столбцов в табличном наборе. Термин степень столбца (degree of a column) указывает на его положение в последовательности столбцов слева направо, начиная с 1
deployment поставка	Процесс развертывания и инсталляции компонентов программного обеспечения для промышленного использования
dialect диалект	Термин, который отличает родной для Firebird язык от старого языка, который был реализован в предшественнике Firebird, InterBase 5. Старая версия языка остается доступной в Firebird с близкой совместимостью со старыми базами данных в виде диалекта 1. Родным для Firebird является диалект 3
DML	Аббревиатура от Data Manipulation Language (язык манипулирования данными), основного подмножества операторов SQL, которые выполняют операции над наборами данных
domain домен	Возможность SQL Firebird, благодаря которой вы можете присваивать конкретному имени множество характеристик данных и ограничений (CREATE DOMAIN), а затем использовать это имя вместо типа данных при определении столбцов таблицы
DPB	Аббревиатура от Database Parameter Buffer (буфер параметров базы данных), символьного массива, определенного в API Firebird. Он используется приложениями для передачи параметров, определяющих характеристики требуемого клиентского соединения вместе с конкретными значениями элементов
DSQL	Аббревиатура от Dynamic SQL (динамический SQL). DSQL определяет операторы, которые приложение передает во время выполнения, с параметрами или без них, в противоположность операторам «статического SQL», которые кодируются непосредственно в специальных блоках кода в программе на языке программирования, а затем обрабатываются препроцессором (например, GPRE) при компиляции приложений со «встраиваемым SQL». Приложения, применяющие вызовы API Firebird в «сыром» виде или через библиотеку классов, которая инкапсулирует API Firebird, также используют DSQL
DTP	Аббревиатура от desktop publishing (настольная публикация), деятельности по использованию средств компьютера для подготовки документов к публикации на принтере или для Web
DUDLEY	Внутреннее имя исходного кода для устаревшей утилиты работы с метаданными gdef. Имя, производное от аббревиатуры DDL
dyn или DYN	Кодированный по байтам язык для описания операторов определения данных. Подсистема DSQL в Firebird выполняет синтаксический анализ операторов DDL и передает их компоненту, который выводит DYN для интерпретации другой подсистемой, которая ответственна за изменение системных таблиц
error ошибка	Условие, при котором запрашиваемая операция SQL не может быть выполнена по причине ошибочности данных, предоставленных в операторе или в процедуре, или из-за ошибки синтаксиса самого оператора. Когда Firebird встречает ошибку, он не продолжает выполнять запрос, и возвращает клиентскому приложению сообщение об исключении. См. также exception
error code код ошибки	Целочисленная константа, возвращаемая клиенту или вызвавшей процедуре, когда Firebird встречает ошибку. См. также error, exception
ESQL	Аббревиатура для Embedded SQL (встроенный SQL), подмножества SQL, предназначенного для статичных операторов SQL, встроенных в специальные блоки в приложениях на каком-либо языке программирования
event событие	Реализованная в Firebird возможность передачи сообщений «слушающим» клиентским приложениям через вызовы POST EVENT в триггерах или хранимыхпроцедурах
exception исключение	Реакция сервера Firebird в ответ на ошибочную ситуацию, которая появилась в процессе выполнения операции с базой данных. Несколько сотен ситуаций, вызывающих исключение, реализовано в виде кодов ошибок различных категорий, которые передаются клиенту в векторе состояния ошибки (массив). Исключения доступны также в хранимых процедурах и триггерах, где они могут быть обработаны в пользовательской подпрограмме. Firebird также поддерживает исключения, определенные пользователем
external function внешняя функция	Firebird имеет несколько (немного) встроенных стандартных функций SQL. С целью расширения количества функций, доступных для использования в выражениях, ядро Firebird может обращаться к пользовательским функциям, написанным на языке программирования, таком как С, C++ или Delphi, как если бы они были встроенными. Несколько готовых свободно распространяемых библиотек внешних функций (также называемых функциями, определенными пользователем, User-Defined Function, UDF) существуют в сообществе Firebird. Две из них включены в дистрибутив Firebird
executable stored procedureвыполняемая хранимая процедура	Хранимая процедура, которая вызывается оператором EXECUTE PROCEDURE и не возвращает многострочного результирующего набора. См. также selectable stored procedure
execute выполнение	В клиентском приложении термин выполнение обычно используется как глагол, означающий «выполнение моего запроса», когда оператор манипулирования данными или вызов хранимой процедуры подготовлен клиентским приложением.В DSQL фраза EXECUTE PROCEDURE используется вместе с идентификатором хранимой процедуры и ее входными параметрами для вызова выполняемой хранимой процедуры
FIBPlus	Торговая марка расширенной коммерческой версии компонентов FreelBComponents- компонентов доступа к данным, инкапсулирующим функции API Firebird и InterBase, для использования в продуктах Borland Delphi, C++ Builder и Kylix
foreign key внешний ключ	Формальное ограничение для столбца или группы столбцов в одной таблице, которая связана с соответствующим первичным или внешним ключом другой таблицы. Если внешний ключ не является уникальным, а сама таблица имеет первичный ключ, то таблица способна поддерживать отношение один-ко-многим. i Firebird поддерживает объявление формального ограничения внешнего ключа, которое будет автоматически поддерживать ссылочную целостность. Если объявлено подобное ограничение, Firebird автоматически создает неуникальный индекс для столбца или столбцов, для которых применяется это ограничение, а также сохраняет зависимости между таблицами, связанными этим ограничением
garbage collection сборка мусора	Общий термин для процесса очистки базы данных, который выполняется в базе данных в процессе обычного ее использования при удалении устаревших версий строк, которые были изменены. В Суперсервере сборка мусора выполняется как фоновый поток главного серверного процесса. Сборка мусора может также выполняться при чистке (sweep) и во время создания резервной копии базы данных
gbak	Утилита командной строки (располагающаяся в каталоге /bin вашего каталога инсталляции Firebird), которая выполняет резервное копирование и восстановление базы данных. Она не является программой копирования файла; ее операция копирования выполняет упаковку метаданных и данных и сохраняет их раздельно в сжатом двоичном формате в файловой системе. По соглашению файлы копий часто имеют расширение gbk или fbk. Восстановление выполняет распаковку этого файла и восстанавливает базу данных как новый файл базы данных до помещения в базу данных объектов данных и пересоздания индексов.Помимо обычных задач обеспечения безопасности базы данных, ожидаемых от утилиты копирования, gbak выполняет важную роль в регулярном поддержании «гигиены базы данных» и в восстановлении разрушенных баз данных
GDML	Аббревиатура для Groton Data Manipulation Language (язык манипулирования данными Groton), реляционного языка, похожего на SQL. GDML был первоначальным языком манипулирования данными для InterBase, функционально эквивалентным языку DML в SQL Firebird, но с некоторыми возможностями определения данных. Он все еще поддерживается в интерактивной утилите запросов qli
gdef	Старая утилита InterBase для создания и манипулирования метаданными. Поскольку isql и интерфейс динамического SQL могут обрабатывать DDL, в gdef теперь нет необходимости. Однако так как она может выводить операторы языка DYN для некоторых языков программирования, таких как С, C++, Pascal, COBOL, ANSI COBOL, Fortran, BASIC, PLI и ADA, она все еще используется в разработке приложений со встраиваемым SQL
generator генератор	Средство генерирования чисел для создания последовательности уникальных чисел. Оператор CREATE GENERATOR имя-генератора создает специальную хранимую 64-битовую переменную. Оператор SET GENERATOR то n устанавливает первое значение этой переменной. Функция GEN_ID (имя-генератора, m) приводит к генерации нового числа, которое на m больше, чем последнее сгенерированное число
gfix	Утилита командной строки, выполняющая ряд действий по ремонту базы данных, активации теневых копий базы данных (shadow), переводу базы данных в режим одного пользователя (исключительный доступ, останов базы данных), а также восстановлению режима базы данных для доступа многих пользователей (рестарт базы данных), gfix также может исправлять зависшие транзакции 2РС, устанавливать размер кэша базы данных, включать или выключать режим синхронной записи на диск, выполнять чистку и устанавливать интервал очистки, переключать базу данных Firebird из режима чтения/записи в режим только чтение и наоборот, а также устанавливать диалект базы данных
gpre	В разработке приложений со встроенным SQL это препроцессор для блоков статического языка SQL в исходном коде языка программирования, который транслирует данный код в формат BLR при подготовке к компиляции. Он может выполнять препроцес- сорную обработку текста на языках С, C++, COBOL, Pascal и ADA на ряде платформ
grant/revokeпредоставление/отмена	Команды SQL GRANT и REVOKE, которые используются для установления и отмены привилегий пользователей для доступа к объектам базы данных
Groton	Сокращение для Groton Data System, имени компании, которая первоначально спроектировала и разработала реляционную СУБД, названную InterBase. В итоге из InterBase появился Firebird. Двое из директоров Groton — Jim Starkey и Ann Harrison — активно участвуют в процессе разработки Firebird
gsec	Утилита командной строки безопасности Firebird для управления базой данных на уровне сервера, содержащей имена пользователей и пароли (security.fdb в версии 1.5, isc4.gdb для версии 1.0^[177]), которая применяется для всех пользователей всех баз данных. Эта утилита не может быть использована для создания или изменения ролей, поскольку роли определяются в пользовательских базах данных
gstat	Утилита командной строки, с помощью которой можно получить статистику базы данных Firebird. Она анализирует внутренние структуры, такие как коэффициент заполнения, заголовок страницы, индексные страницы, страницы протокола и системные отношения. Можно также получить информацию о версиях записей (обычно очень объемную) от таблицы к таблице. Для этого нужно использовать совместно переключатели -r и -t имя-таблицы
hierarchical database иерархическая база данных	Старая концепция проектирования для реализации в базе данных отношений таблица-таблица путем создания древовидной структуры наследуемых индексов
host language	Общий термин для языка программирования, на котором написано приложение
identity attribute идентичность атрибута	Некоторые реляционные СУБД (например, MS SQL) поддерживают атрибут таблицы, который автоматически реализует для целого столбца искусственный первичный ключ для таблицы. При этом новое значение такого столбца автоматически генерируется для каждой новой добавляемой строки. Firebird напрямую не поддерживает такой атрибут. Похожий механизм может быть получен явным определением целочисленного столбца соответствующего размера, созданием генератора для получения значений этого столбца и определением триггера BEFORE INSERT, который вызывает функцию GEN_ID() для получения следующего значения генератора
IBO	Аббревиатура для IB Objects, компонентов доступа к данным и связанными с данными управляющими элементами, инкапсулирующими API Firebird и InterBase для использования в продуктах Borland Delphi, C++ Builder и Kylix
IBX	Аббревиатура для InterBase express, компонентов доступа к данным, инкапсулирующих API InterBase, распространяемых фирмой Borland вместе с продуктами Delphi и C++ Builder
index индекс	Специализированная структура данных, поддерживаемая ядром Firebird, которая предоставляет компактную систему указателей на строки в таблице
INET error ошибка сети	В firebird.log отмечаются ошибки, полученные сетевой подпрограммой Firebird от соединений клиент-сервер, использующих протокол TCP/IP
installation инсталляция	Процедура и процесс копирования программного обеспечения на компьютер и его конфигурирования для использования
InterBase	Реляционная СУБД, которая была предшественником Firebird. Разработанная вначале в компании Gorton Data Systems, она в итоге перешла во владение компании Borland Software Corporation. InterBase 6 был реализован в открытых кодах в 2000 году в рамках InterBase Public License. Firebird был разработан независимыми разработчиками из этих открытых кодов и вскоре стал разветвленной разработкой
InterClient	Устаревший клиент Java типа 2 JDBC для сервера InterBase 6. В Firebird он замещен системой JayBird из семейства драйверов с открытыми кодами, совместимыми с JDBC/JCA (тип 2 и тип 4)
InterServer	Устаревшая оболочка, основанная на сервере управляемом драйвером Java, поставляемая с открытыми кодами InterBase 6. Как InterServer, так и сопутствующий ему InterClient заменены в Firebird на JayBird, более новый интерфейс Java с открытым кодом
ISC, isc и т.д.	Сообщения об ошибках, некоторые переменные окружения и многие идентификаторы в API Firebird имеют префикс «ISC» или «isc». С точки зрения чисто исторического интереса можно сказать, что эти начальные символы являются производными от начальных букв «InterBase Software Corporation», имени дочерней компании Borland, которая существовала в процессе некоторого периода, когда Borland владел предшественником Firebird — InterBase
isolation level уровень изоляции уровень изолированности	Этот атрибут транзакции описывает способ, каким транзакция будет взаимодействовать с другими транзакциями, имеющими доступ к той же самой базе данных, в терминах видимости и поведения при блокировке. Firebird поддерживает три уровня изоляции: READ COMMITTED (подтвержденное чтение), REPEATABLE READ (повторяемое чтение, также называемое SNAPSHOT, мгновенный снимок, или CONCURRENCY, параллельность) и SNAPSHOT TABLE STABILITY (согласованность). Хотя READ COMMITTED является значением по умолчанию для большинства реляционных систем, значением по умолчанию для Firebird является SNAPSHOT (уровень изолированности READ COMMITTED был реализован в InterBase много позже SNAPSHOT). см. также transaction isolation
isql	Название для интерактивной утилиты запросов командной строки Firebirds, которая единовременно может соединяться только с одной базой данных. Она имеет мощный набор команд, включающих свое собственное подмножество команд SQL Firebird в дополнение к обычному набору команд динамического SQL. Она содержит обширный набор включенных макросов для получения информации о метаданных, isql может выводить наборы команд, в том числе включенные комментарии в файл, и может также «запускать» наборы команд в. виде скриптов- рекомендуемый способ создания и изменения объектов базы данных
JDBC	Аббревиатура для Java DataBase Connectivity, набора стандартов для создания драйверов для соединения приложений Java с базами данных SQL
joinсоединений	JOIN является ключевым словом для указания серверу, что результат оператора SELECT включает объединение столбцов из нескольких таблиц, связанных соответствием одной или более пар ключей
jrd	Внутреннее имя для ядра базы данных Firebird. Оно является аббревиатурой для Jim’s Relational Database (реляционная база данных Джима), продуктом основного ядра, введенным Джимом Старки (Jim Starkey), который стал ядром InterBase и, позже, Firebird
key ключ	Ограничение таблицы, применимое к столбцу или группе столбцов в структуре строк таблицы. Первичный ключ или уникальный ключ указывают на уникальную строку, в которой они присутствуют, в то время как внешний ключ указывает на уникальную строку другой таблицы посредством связи с ее первичным ключом или другим уникальным ключом
kill (shadows) уничтожение теневой копии	Когда теневая копия (shadow) базы данных создается с использованием ключевого слова MANUAL и оперативная копия становится недоступной, дальнейшие соединения с базой данных блокируются. Для восстановления возможностей соединений с базой данных необходимо выполнить команду gfix -kill база-данных для удаления ссылок на теневую копию
leaf bucket сегменты листьев	В индексном дереве b-tree элемент данных в последнем индексе узла дерева. Число сегментов листьев, полученное в статистике индекса утилитой gstat, дает приблизительное количество строк таблицы
limbo (transaction) зависшая транзакция	Зависшая транзакция может появиться, когда транзакция стартует над несколькими базами данных (2PC). Транзакции со многими базами данных защищены двухфазным подтверждением, что гарантирует, что без подтверждения частей транзакции для каждой базы данных для всей транзакции будет выполнен откат. Если одна или несколько баз данных, используемых в транзакции, станут недоступными до завершения двухфазного подтверждения, транзакция останется в неопределенном состоянии. Такую транзакцию называют зависшей
locking conflict конфликт блокировок	В оптимистической схеме блокировок Firebird строка становится заблокированной для изменений другими транзакциями в тот момент, когда ее транзакция посылает запрос на ее изменение. Если транзакция имеет уровень изоляции SNAPSHOT TABLE STABILITY (также называемый Consistency), блокировка возникает, когда транзакция читает строку. Конфликт блокировок появляется, когда другая транзакция пытается послать свои собственные изменения для этой строки. Конфликты блокировок имеют множество причин, характеристик и способов разрешения в соответствии с заданными установками в транзакциях, вовлеченных в конфликт
lock resolution разрешение блокировки	Общий термин, означающий меры, принятые кодом приложения для разрешения условий, когда другие транзакции пытаются изменить строку, которая была заблокирована транзакцией, пославшей запрос на изменение. В качестве специфического термина разрешение блокировки означает установку в транзакции параметра WAIT/NOWAIT, который определяет реакцию транзакции на возникший конфликт блокировки
metadata метаданные	Общее существительное, означающее структуру всех объектов, содержащихся в базе данных. Поскольку Firebird хранит определения объектов базы данных в самой базе данных, используя свои таблицы, типы данных и триггеры, термин «метаданные» также означает данные, хранящиеся в этих системных таблицах
multi-generational architecture (MGA)многоверсионная архитектура	Термин, применяемый в отношении ядра Firebird, использующего оптимистическое блокирование записей и высокий уровень изолированности транзакций, позволяющий транзакциям видеть свои и чужие изменения без блокировок чтения. Достигается путем \|хранения ядром множества версий одной записи и определения «возраста» этих версий по отношению к конкретной транзакции. \| См. также versioning architecture
natural (scan)естественное сканирование	Указывает, что соответствующая таблица будет просматриваться в «естественном порядке» (то есть вне определенного порядка и без использования какого-либо индекса). Иногда это видно в планах запросов, созданных оптимизатором
next transaction следующая транзакция	Номер, который будет выдан ядром Firebird очередной транзакции. Может быть просмотрен в статистике, извлекаемой утилитой gstat с ключом -header
non-standard SQL нестандартный SQL	Термин, который часто можно услышать при ссылках на реляционные СУБД, имеющие низкий уровень соответствия языку ISO и стандарту синтаксиса SQL. См. также standard SQL
non-unique key неуникальный ключ	Столбец или группа столбцов, которые могут служить указателем на группу строк в наборе. Ограничение внешнего ключа, используемое для реализации отношения один-ко-многим, создается для соответствия неуникального столбца или группы столбцов в «дочернем» или «детальном» наборе уникальному ключу в «родительском» или «главном» наборе
normalization нормализация	Общая техника, используемая при анализе данных до начала проектирования базы данных с целью устранения повторяющихся групп во множестве таблиц и уменьшения дублирования одних и тех же «фактов» в связанных таблицах
nullпустое значение	Иногда неправильно называется «нулевым значением». Состояние элемента данных, который не имеет известного значения. Логически это интерпретируется как неизвестное значение и по этой i причине не может быть использовано при вычислении выражений.NOLL не эквивалентен нулю, пробелу или пустой строке (строке с i нулевой длиной); он не представляет бесконечности. Он представляет состояние элемента данных, которому либо не было присвоено значение, либо было присвоено NOLL
ODBC	Аббревиатура для Open DataBase Connectivity (открытый интерфейс доступа к базам данных). Это стандарт интерфейса на уровне вызовов, который позволяет приложениям получить доступ к данным в любой базе данных, для которой есть драйвер, поддерживающий этот стандарт. Существует ряд драйверов ODBC, поддерживающих Firebird, включая драйвер с открытыми исходными текстами, внутренне соответствующий стандарту JDBC
ODS	Аббревиатура для Оп-Disk Structure (структура на диске). Это число, которое указывает на версию внутренней структуры и формата базы данных Firebird или InterBase. Для InterBase 4.0 это 1 было 8, для InterBase 4.2 было 8.2, а для InterBase 5- 9. Firebird 1 имел ODS 10, а 1.5 — 10.1.Базу данных можно перевести в более высокий уровень ODS, выполнив ее копирование gbak -b[ackup] -t[ransportable] с использованием старой версии программы gbak и восстановив из этого файла копии с использованием новой версии gbak
OLAP	Аббревиатура для OnLine Analytical Processing (онлайновая аналитическая обработка данных) технологии, которая применима к базам данных, вырастающим до таких размеров, что к ним непрактично обращаться напрямую в качестве основы деловых решений. Обычно системы OLAP разрабатываются для анализа и графического представления, идентификации и фиксирования исторических этапов или аномалий, создания проекций и гипотетических сценариев, сжатия больших объемов данных для отчетов и т.д.
OS	Аббревиатура для Operating System (операционная система)
Oldest Active Transaction (OAT)старейшая активная транзакция	Статистика, поддерживаемая сервером Firebird, глобальная для базы данных. Старейшая транзакция, все еще находящаяся в базе данных, которая не была ни подтверждена, ни отменена
Oldest Interesting Transaction (OIT) старейшая заинтересованная транзакция^[178]	Статистика, поддерживаемая сервером Firebird, глобальная для базы данных. Идентификатор старейшей транзакции, которая была завершена по rollback. Когда номер OIT «застревает» при продвижении всех остальных номеров транзакций вперед, сборка мусора (чистка от старых версий записей) не может продолжаться, и операции с базой данных сильно замедляются, а в итоге полностью зависают^[179] . Номер OIT может быть просмотрен при использовании переключателя -header утилиты командной строки gstat
OLE DB	Аббревиатура от Object Linking and Embedding for DataBases (встраивание и связывание объектов для баз данных). OLE является стандартом Microsoft, разработанным и продвигаемым для включения двоичных объектов множества различных типов (изображения, документы и т.д.) в приложения Windows вместе со связями на уровне приложений с программными объектами, которые их создают и изменяют. Средство OLE DB было введено в качестве попытки предоставить разработчикам средства для обеспечения более специфичной для конкретного поставщика поддержки соединений с базами данных- в первую очередь для реляционных баз данных, — с которыми можно работать с помощью ODBC. Позже Microsoft создал технологию ADO над OLE DB
OLTP	Аббревиатура для OnLine Transaction Processing (онлайновая обработка транзакций), рассматриваемая как одно из основных требований к ядру базы данных. Вообще говоря, OLTP больше относится к поддержке клиентов, выполняющих чтение, изменение или создание данных в реальном режиме времени
optimization оптимизация	В самом широком смысле означает техники, позволяющие сделать выполнение программного обеспечения приложений и баз данных настолько эффективным, насколько это возможно. Как специфический термин, он часто используется ядром Firebird при анализе операторов SELECT и построении эффективных планов для поиска данных. Подпрограммы ядра Firebird, которые просчитывают эти планы, вместе называются оптимизатором Firebird
page страница	База данных Firebird состоит из блоков дискового пространства фиксированной длины, называемых страницами. Firebird выделяет страницы по мере необходимости. Поскольку страница хранит данные, она может быть страницей одного из десяти типов страниц, все одинакового размера — размера, определенного в атрибуте PAGE_SIZE В процессе создания базы данных. Тип страницы, сохраняемой на диске, зависит от типа объекта данных, сохраняемого на странице: данные, индекс, BLOB и т.д.
page_size	Размер каждого фиксированного блока определяется в атрибуте PAGE_SIZE, задаваемом для базы данных при создании или восстановлении базы данных. Участки памяти для кэша базы данных также выделяются в единицах PAGE SIZE
parameter параметр	Широко распространенный термин во множестве контекстов Firebird. Он может именовать значения, передаваемые в качестве аргументов хранимой процедуре и получаемые из хранимой процедуры (входные и выходные параметры). Термин также может означать элементы данных, которые передаются в блоках функций API Firebird (блок параметров базы данных, блок параметров транзакции, блок параметров сервиса), или атрибуты, видимые в приложении при соединении с базой данных (параметры соединения) или атрибуты транзакции (параметры транзакции). В клиентских приложениях синтаксические элементы, которые передаются предложениям WHERE операторов SQL для подстановки значений во время выполнения, часто реализованы в виде «параметров». Отсюда термин «параметризованные запросы»
PHP	Аббревиатура для PHP: Hypertext Preprocessor (гипертекстовый препроцессор). Это язык скриптов встроенного HTML с открытыми исходными кодами, применяемый для создания приложений Web, особенно тех, которые используют базы данных. Он имеет хорошую поддержку множества сетевых протоколов и окружений программирования для Web. Его сильная сторона — совместимость со многими типами баз данных. PHP также может общаться по сетям, использующим IMAP, SNMP, NNTP, POP3 или HTTP. Изобретателем PHP был Расмус Ледорф (Rasmus Lerdorf) в 1994 году. С 1997 года PHP находится в руках большого сообщества открытых исходных текстов
plan план	См. query plan
platform платформа	Термин, неточно используемый для названия комбинации аппаратных средств и программного обеспечения операционных систем или только одного программного обеспечения операционной системы, например, «платформа Windows 2000», «платформа Linux», «платформы UNIX». Кроссплатформенность обычно означает «применимое на множестве платформ» или «переносимое на другие платформы»
prepare подготовка	Функция API, которая вызывается перед первой отправкой запроса. Она запрашивает у сервера проверку оператора, создание плана запроса и некоторых информационных элементов относительно ожидаемых данных
primary key первичный ключ	Ограничение на уровне таблицы, отмечающее столбец или группу столбцов как ключ, который должен уникально идентифицировать каждую строку в таблице. Хотя таблица может иметь более одного уникального ключа, только один из этих ключей может быть первичным. Когда вы применяете ограничение PRIMARY KEY К столбцам в таблице Firebird, уникальность будет поддерживаться с помощью автоматически созданного уникального индекса, который по умолчанию будет возрастающим и будет назван в соответствии с соглашениями
PSQL	Аббревиатура для Procedural SQL (процедурный SQL), подмножества расширенного SQL, созданного для написания хранимых процедур и триггеров. Существует небольшая разница между подмножествами PSQL, используемыми для хранимых процедур и для триггеров
qli	Это Query Language Interpreter (интерпретатор языка запросов), интерактивный клиентский инструмент запросов для Firebird. Он может обрабатывать операторы DDL и DML из SQL и GDML (языка, используемого в предшественнике Firebird — InterBase 3). Хотя уже есть isql и другие инструменты графического интерфейса сторонних разработчиков, qli все еще имеет значение по причине его способности осуществлять некоторые операции, до сих пор не реализованные в SQL Firebird. В отличие от isql, qli может одновременно соединяться более чем с одной базой данных и может симулировать обращение к нескольким базам данных в одном запросе
query запрос	Общий термин для любого обращения SQL к базе данных, поступающего от клиентского приложения к серверу
query plan план запроса	Стратегия использования индексов и методов доступа для сортировки и поиска при выполнении запросов. Оптимизатор Firebird всегда создает план для каждого запроса SELECT, включая и подзапросы. Можно задать пользовательский план с использованием синтаксиса предложения PLAN
RDB$-	Префикс, который мы видим в идентификаторах многих созданных системой объектов Firebird. Это след от Relational DataBase, имени более ранней реляционной базы данных, разработанной в DEC. Созданная система RDB была предшественницей InterBase, прообраза Firebird. Наследником RDB также является СУБД Oracle
RDB$DB_KEY	Скрытый, непостоянный, уникальный ключ, который вычисляется в ядре Firebird для каждой строки таблицы из физического адреса страницы, на которую помещается строка, и ее смещения от начала страницы. Он напрямую связан с кардинальностью таблиц и наборов и может изменяться без предупреждений. Он всегда будет меняться при восстановлении базы данных из резервной копии. RDB$DB_KEY никогда не должен трактоваться как постоянный. С аккуратностью он может быть использован в пределах одной атомарной операции для значительного ускорения некоторых операций в DSQL и PSQL
RDBMS реляционная СУБД, РСУБД	Аббревиатура для Relational DataBase Management System (реляционная система управления базами данных). Это общая концепция хранения данных в соответствии с абстрактной моделью, которая использует соответствие ключей для связи одних формально сгруппированных данных с другими сгруппированными данными, представляя, таким образом, отношение между двумя группами
Read Committed подтвержденное чтение	Наименее ограничивающий уровень изоляции для транзакций Firebird. Read Committed позволяет транзакции перечитывать данные и видеть подтвержденную работу других транзакций после начала выполнения данной транзакции. Уровни изоляцииSNAPSHOT и SNAPSHOT TABLE STABILITY не позволяют видеть чужие подтвержденные изменения
redundancy избыточность	Условие в базе данных, когда два одинаковых «факта» хранятся в двух не связанных местах. В идеале избыточность должна быть устранена в процессе нормализации при анализе данных. Однако существуют некоторые условия, при которых оправдано некоторое количество избыточности. Например, бухгалтерские проводки часто содержат элементы данных, которые возможно могли бы быть получены из соединений, выборки или вычислений из других структур. Однако узаконенным требованием является сохранение постоянной записи, которая не будет изменяться, если последующее изменение отношения в базе данных будет отменять условие сокращения избыточности
redundant indexes избыточные индексы	Избыточные индексы часто появляются, когда существующая база данных импортируется в Firebird из других реляционных СУБД. Когда ограничение PRIMARY KEY, UNIQUE или FOREIGN KEY применяется к столбцу или столбцам, Firebird автоматически создает индекс для поддержания этого ограничения. Сделав это, Firebird игнорирует все существующие индексы, дублирующие автоматические индексы. Наличие дубликатов индексов для ключей или других столбцов может нарушить работу оптимизатора запросов, приводя к созданию очень медленных планов
referential integrity ссылочная целостность	Обычно означает, каким образом реляционная СУБД реализует механизм для формальной поддержки и защиты зависимостей между таблицами. Поддержка ссылочной целостности означает наличие элементов языка и синтаксиса, доступных для предоставления таких возможностей.Firebird предоставляет формальный механизм для поддержки ссылочной целостности, включающий каскадные ограничения для отношений внешнего ключа. Это иногда называется декларативной ссылочной целостностью
relation отношение	В теории реляционных баз данных это замкнутый набор данных, формально распределенный по столбцам и строкам. Этот термин также взаимозаменяем с термином «таблица» за исключением того, что отношение не может иметь дублированных строк, когда таблица это может. Существующая терминология в Firebird эти имена относит к системным таблицам (например, к таблице RDB$RELATIONS, которая содержит записи для каждой таблицы базы данных)
relationship отношение	Абстрактный термин, указывающий на то, как отношения (или таблицы) связаны с другими через соответствующие ключи. Например, таблица Order Detail (детальная запись заказа) будет находиться в отношении зависимости или в отношении внешнего ключа с таблицей Order Header (заголовок заказа)
replication репликация	Систематический процесс, с помощью которого записи копируются из одной базы данных в другую на регулярной основе в соответствии с заранее определенными правилами, с целью перевода двух или более баз данных в синхронное состояние
result table результирующая таблица	Набор строк, являющихся результатом запроса SQL SELECT. Более точно этим термином называют результирующий набор, синоним выходного набора
roles роли	Стандартный механизм SQL для определения набора полномочий по использованию объектов базы данных. Когда создана роль, назначение ей полномочий осуществляется операторами GRANT, как если бы она была обычным пользователем. Затем роль можно назначать (GRANT) индивидуальным пользователям, как если бы она была привилегией. Таким путем упрощается поддержка полномочий пользователей к базе данных
rollback откат (транзакции)	Действие или процесс по отмене всей работы, которая была выполнена во время транзакции. Пока у транзакции есть работа, ожидающая завершения, отправленная на сервер, но не подтвержденная, она остается незавершенной и ее результаты не видны другим транзакциям. Если клиентское приложение вызывает ROLLBACK, вся отправленная работа отменяется, а изменения теряются. Если же транзакция подтверждается, то ее работа не может быть отменена
schema схема	Формальное описание базы данных, обычно помещенное в скрипт или скрипты, содержащие операторы SQL, определяющие каждый объект базы данных. Термин «схема» часто заменяется термином «метаданные»
schema cache кэш схемы	Механизм, при котором некоторые описательные элементы базы данных сохраняются на локальном клиентском диске или в оперативной памяти для быстрого обращения во время выполнения с целью устранения необходимости постоянно обращаться к базе данных для получения атрибутов схемы (метаданных)
scrollable cursor прокручиваемый курсор	Курсор является указателем на строку в таблице базы данных или в выходном наборе. Позиция курсора в базе данных определяется кардинальностью строки, на которую он в настоящий момент указывает (то есть смещением этой строки относительно первой строки в наборе). Изменение позиции курсора требует возврата указателя к первой строке для поиска новой позиции. Прокручиваемый курсор способен самостоятельно помещаться на заданную новую позицию (вверх или вниз) относительно его текущей позиции (не поддерживается в Firebird)
selectivity of an index	*
селективность индекса, избирательность индекса	Как общий термин означает диапазон возможных значений для столбца индекса во всей таблице. Чем меньше возможных значений, тем ниже селективность. Низкая селективность также может появиться, когда индекс с большим количеством возможных значений представлен фактическими данными с очень большим количеством дубликатов небольшого количества значений. Низкая селективность — это плохо, высокая — хорошо. Уникальный индекс имеет максимально возможную селективность^[180]
selectable stored procedure хранимая процедура выбора	Хранимая процедура, написанная с использованием специального синтаксиса PSQL для вывода многострочного результирующего набора вызвавшему объекту. Она вызывается с использованием оператора SELECT. см. также executable stored procedure
Services API сервисы API	API для обращения к функциям некоторых серверных утилит Firebird, таким как резервное копирование, статистика, sweep и др. Сервисы API могут быть неприменимыми к некоторым версиям Классического сервера
sets наборы	В терминах реляционной базы данных набор это множество данных, содержащее одну или более строк, состоящих из одного или более столбцов данных, где каждый столбец состоит из одного элемента данных заданного размера и типа. Например, спецификация запроса SELECT или просмотр определяют выходной набор для клиентского приложения или модуля PSQL, в то время как спецификация запроса UPDATE определяет набор, с которым выполняется заданная операция
shadowing/shadows теневое копирование / теневые копии	Процесс, доступный на сервере Firebird, при котором в реальном времени поддерживается точная копия базы данных со всеми изъянами и недостатками на отдельном жестком диске той же серверной машины, где располагается и база данных. Такая копия называется теневой копией базы данных. Ее назначением является обеспечение возможности быстрого продолжения работы после физического повреждения жесткого диска, на котором размещается база данных. Теневая копия не является подходящим заменителем для репликации или копирования
SMP	Аббревиатура для Symmetric Multiprocessing (симметричный мультипроцессор), архитектуры компьютера, которая делает множество процессоров доступными для выполнения одновременных индивидуальных процессов одной операционной системой. По теории любой незанятый процессор может быть назначен любой задаче, и чем больше процессоров в системе, тем выше производительность и пропускная способность
Snapshot «мгновенный снимок»	SNAPSHOT является одним из трех уровней изоляции транзакций, поддерживаемых Firebird. Он обеспечивает стабильный вид базы данных, который остается постоянным для пользователя транзакции на время жизни этой транзакции. Он также называется конкурентным уровнем изоляции. См. также Read Committed, Snapshot Table Stability
Snapshot Table Stability	SNAPSHOT TABLE STABILXTY является самым защищенным из трех уровней изоляции транзакций в Firebird. Он поддерживает согласованный вид базы данных для пользователя транзакции, не позволяя другим транзакциям изменять любую считанную им строку, даже если транзакция еще не посылала никаких изменений. Он еще называется согласованным уровнем изоляции. См. также Read Committed, Snapshot
SQL	Язык запросов, разработанный для извлечения осмысленных наборов данных из реляционной базы данных. Его правильное произношение «эс-кью-эль», а не «сиквел», как думают некоторые люди («сиквел» было именем другого языка запросов). К тому же это не является аббревиатурой от Structured Query Language^[181]^[182]
standard SQL, SQL standard стандарт SQL	Означает синтаксис и реализацию элементов языка SQL, который опубликован ISO (International Organization for Standardization, Международная организация по стандартизации). Это очень сложные описания стандарта вместе с всеобъемлющим синтаксисом и функциональностью на множестве уровней
stored procedure хранимая процедура	Компилированный модуль, хранимый в базе данных для вызова приложениями или другими модулями, хранимыми на сервере (триггерами, другими хранимыми процедурами). Она определяется в базе данных на исходном языке- процедурном SQL, или PSQL — и состоит из обычных операторов SQL, а также из специальных, расширений языка SQL, которые поддерживают структуры, циклы, условную логику, локальные переменные, входные и выходные аргументы, обработку исключений и др.
subquery подзапрос	Спецификация запроса, который может определить выходные столбцы, которые получаются из выражений. Подзапрос является специальным видом выражения, которое возвращает результат, являющийся выходным набором оператора SELECT. Его также называют подвыбором или встроенным запросом
sub-select, subselect подвыбор	Столбец подвыбора является столбцом, который получается в результате подзапроса. Такие столбцы не являются изменяемыми. См. также subquery
Superserver architecture архитектура Суперсервера	Суперсервер является именем многопользовательской модели с потоками (threads) в отличие от начальной модели InterBase, которая использует отдельный серверный процесс для каждого клиентского соединения. Первоначальная модель сейчас называется Классическим сервером
surrogate key искусственный (суррогатный) ключ	В определении уникального ключа (например, первичного ключа) он может появиться, когда нет столбца или комбинации столбцов, которые могли бы гарантировать уникальную идентификацию каждой строки. В этом случае может быть добавлен столбец, получающий значения, которые точно являются уникальными. Такой ключ называется искусственным ключом
sweeping чистка	Процесс, который собирает и освобождает устаревшие версии каждой записи в базе данных, когда достигнут заданный порог. Это число, которое имеет значение по умолчанию 20 000 и называется интервалом чистки, вычисляется как разность между OIT и OST. Автоматическая чистка может быть отменена установкой интервала чистки в ноль. Ручная чистка может быть вызвана специально с помощью утилиты gfix. Чистка не используется в реляционных СУБД, которые не сохраняют устаревшие версии записей
SYSDBA	Аббревиатура для system database administrator (системный администратор базы данных), человека, ответственного за администрирование баз данных
system tables системные таблицы	Поскольку ядро сервера базы данных является самодостаточным, все метаданные или схемы (данные, которые описывают структуру и атрибуты объектов базы данных) поддерживаются в базе данных в виде набора таблиц, которые создаются командой CREATE DATABASE. Такие таблицы, которые хранят «данные о данных», называются системными таблицами. Все системные таблицы Firebird имеют идентификаторы, которые начинаются с префикса RDB$И содержат данные о себе, так же как и данные о каждом другом объекте в базе данных
table таблица	Термин заимствован из технологии настольных баз данных, описывает логическую структуру, которая хранит наборы данных в табличном формате в виде записей (строк) полей, где все строки по определению идентичны слева направо по количеству и относительному положению полей и их типов данных и размеров. В действительности Firebird хранит данные не в физически табулированной форме, а в смежных блоках дискового пространства, называемых страницами
transaction транзакция	Логическая единица работы, которая может включать один или более операторов. Транзакция начинается, когда ее запускает клиентское приложение, и завершается, когда приложение выполняет ее подтверждение или откат. Транзакция является атомарным действием — подтверждение должно быть способным подтвердить каждую часть работы, иначе вся ее работа будет ликвидирована. Откат, аналогично, отменит все части работы, которая была отправлена на сервер с момента старта транзакции
transaction isolation изоляция транзакции, уровень изолированности транзакции	Механизм, при котором каждая транзакция поддерживается окружением так, что она воспринимает себя, как если бы она выполнялась одна в базе данных. Когда одновременно выполняется множество транзакций, то действия всех других транзакций не видны каждой транзакции, если на момент ее старта эти действия не были подтверждены. Firebird поддерживает не один, а три уровня изоляции, включая один уровень, который может видеть результаты работы других транзакций, когда они подтверждаются. См. Read Committed, Snapshot, Snapshot Table Stability
transitively dependent транзитивно зависимый	Ограничение или условие, при котором одна таблица С является зависимой от другой таблицы А, потому что таблица С зависит от другой таблицы В, которая зависит от таблицы А. Подобная зависимость может, например, возникать, если таблица В имеет внешний ключ, ссылающийся на первичный ключ таблицы А, а таблица С имеет внешний ключ, ссылающийся на первичный ключ таблицы В. Этот термин также используется при моделировании данных для обозначения условий, когда в процессе нормализации атрибут одной сущности имеет частичную (но не полную) зависимость от набора уникальных атрибутов другой сущности
trigger триггер	Скомпилированный модуль, принадлежащий таблице, который выполняет действие, когда происходит событие DML для строки этой таблицы. На событие до и/или после операций добавления, изменения или удаления строки таблицы можно создать любое количество триггеров, используя все возможности процедурного SQL (PSQL)
tuple кортеж	В терминологии реляционных баз данных это «строго корректное» имя для строки в таблице или для группы столбцов, которые являются подмножеством строки. Борцы за чистоту языка скажут,что в SQL кортеж именуется строкой
UDF	Аббревиатура для User Defined Function (функция, определенная пользователем). Более корректно — внешняя функция. См. также external function
unbalanced index несбалансированный индекс	Индексы Firebird поддерживаются в виде структур двоичных деревьев. Про такие структуры говорят, что они разбалансированы^[183] , когда новые узлы все время добавляются таким образом, что это приводит к значительному ветвлению одной «стороны» двоичного дерева. Обычно такое происходит, когда процесс добавляет сотни тысяч новых строк в одной транзакции. По этой причине рекомендуется деактивировать индексы в процессе объемных добавлений. Последующая активация пересоздаст полностью сбалансированные индексы
uninstallation деинсталляция	Уродливое обратное словообразование, путающее говорящих не на английском языке, в то время как оно до сих пор не существует ни в одном уважающем себя словаре! Оно приблизительно означает «процесс, обратный инсталляции» (то есть удаление ранее установленного программного продукта из компьютерной системы)
union объединение	Предложение в спецификации запроса SELECT, которое позволяет строки двух или более операторов SELECT объединять в один конечный выходной набор, если объединяемые наборы соответствуют друг другу по количеству, типам данных и размерам их выходных столбцов. Эти наборы могут быть выбраны из различных таблиц
updatable view изменяемый просмотр	Про просмотр говорят, что он изменяемый, если он получен из обычного запроса к одной таблице и все его столбцы существуют в базовой таблице. Некоторые неизменяемые просмотры могут быть сделаны изменяемыми путем создания для них триггеров. См. также view
validation проверка	Механизм, с помощью которого новые данные, помещаемые в столбец таблицы, проверяются некоторым образом для определения, соответствуют ли они требуемому формату, значению или диапазону значений. Двумя способами реализации проверок в базе данных являются ограничения CHECK и триггеры. Ограничение CHECK будет вызывать исключение, если входные данные не пройдут проверку в существующем выражении или ограничении. В триггерах значение NEW.VALUE может быть протестировано более детально, и если оно ошибочно, то можно выдать пользовательское исключение
versioning architecture версионная архитектура	То же, что и Multi-Generational Architecture (MGA, многоверсионная архитектура). Механизм, создающий новую версию строки при ее изменении или удалении. До COMMIT такая версия не видна другим транзакциям, кроме той, в которой было произведено это изменение или удаление. После COMMIT новая версия записи становится постоянной, а старая становится или устаревшей или все еще актуальной для конкурирующих транзакций (в зависимости от их уровня изолированности). Это позволяет целиком исключить ненужные блокировки чтения, а блокировки модификации возникают только тогда, когда конкурирующие транзакции пытаются обновить одну и ту же запись
view просмотр, представление	Стандартный объект SQL, который хранит спецификацию запроса и ведет себя так же, как и обычная таблица. Просмотр не хранит данные на диске — он действует как предварительно определенный контейнер для набора выходных данных, которые находятся в одной или более таблицах
WNET error ошибка WNET	В протоколе firebird.log отмечает ошибку, полученную сетевой подсистемой Firebird от протокола именованных каналов Windows (Windows Named Pipes) соединения клиент-сервер
XSQLDA	Аббревиатура для extended SQL Descriptor Area (расширенная область дескрипторов SQL). Это структура API, которая используется для передачи данных между клиентским приложением и серверным модулем синтаксического анализа динамического SQL. XSQLDA существуют в двух видах: входные дескрипторы и выходные дескрипторы
XSQLVAR	Структура для определения sqlvar, важного поля в структуре XSQLDA, которая используется для передачи и получения входных и выходных параметров
Y valve затворка Y	Имя, данное подсистеме Firebird, определяющее, который из «внутренних движков» Firebird должен быть использован при подключении к базе данных. Например, использовать локальное подключение или сетевое, или какую функциональность нужно подключить при работе с базой данных, имеющей конкретный номер ODS

Примечания

1

Квадратные скобки могут присутствовать в операторах DDL для задания размерности массивов. -Прим. перев.

(обратно)

2

Не думайте, что копирование файла базы данных на компакт-диск сделает базу данных базой только для чтения. База данных должна быть сделана только для чтения с использованием утилит gbak или gfix до записи на компакт-диск. См. соответствующие главы по инструментам в части IX.

(обратно)

3

Под 64-битовым вводом/выводом имеется в виду поддержка в сервере, операционной системе и файловой системе работы с файлами размером больше 4 Гбайт, что требует не старой 32-битовой адресации, а 64-битовой. Это не имеет отношения к поддержке 64-разрядных процессоров. — Прим. науч. ред.

(обратно)

4

Заметьте, однако, что пользовательские библиотеки внешних функций не являются переносимыми между платформами. Необходимо создавать версии этих библиотек для каждой платформы, на которой может располагаться база данных. Все платформы, поддерживающие Windows, могут использовать те же библиотеки Windows; библиотеки разделяемых объектов для платформ POSIX не обязательно будут выполняться на всех платформах POSIX.

(обратно)

5

Из-за ошибки в Windows использование DummyPacketlnterval может привести к зависанию или краху Windows на клиентской стороне. Объяснения см. в следующей статье Microsoft Support: http://support,microsoft.com/default.aspx?kbid=296265. Не рекомендуется его использовать и в системах, отличных от Windows. Он может даже мешать возможному отключе-

(обратно)

6

По умолчанию [x]inetd в своем файле конфигурации имеет ограничение на число стартуемых экземпляров конктретного сервиса. Это может проявляться как ошибка при подключении очередного пользователя (напрмер, невозможно подключить более 60 пользователей). Отредактируйте файл конфигурации [x]inetd и установите желаемый лимит количества сервисов fb_inet_server, т.е. количества подключний к Классическому серверу FireBird. Прим. науч. ред.

(обратно)

7

Строго говоря, наличие уникального ключа в таблице не является обязательным для реляционных баз данных, хотя его наличие весьма желательно. — Прим. перев.

(обратно)

8

Трудно определить, какой возможен максимальный размер баз данных Firebird. Пользователи сообщают о базах данных в 900 Гбайт, которые еще «продолжают расти».

(обратно)

9

О двухфазном подтверждении транзакций см. в главе 25.

(обратно)

10

Рекомендуется свободно распространяемый драйвер IBProvider Дмитрия Коваленко. Подробности см. на http://www.ibprovider.com/rus/index.html.

(обратно)

11

Список ссылок на документальные источники см. в приложении 12.

(обратно)

12

На этих платформах, не имеющих поддержки сервисов, размещение может быть иным. Необходимо проверять, установлены ли предыдущие клиенты Firebird или InterBase.

(обратно)

13

Встроенный сервер для Linux не соответствует ему же в Windows. Как и в модели под Windows, клиент libfbembed.so Имеет «прямое соединение» с экземпляром сервера. В Linux та же библиотека может создавать экземпляр встpoeннoro сервера на сетевом сервере. Однако libfbembed.so cтpoгo рекомендуется в качестве клиента, если приложение содержит потоки.

(обратно)

14

Официальный инсталлятор и instclient.exe трактуют с: Windowssysteт как «системный каталог» для этих платформ. Некоторые «неофициальные» инсталляторы следуют соглашениям, установленным фирмой Borland для InterBase, как и некоторые инсталляторы Firebird 1.0, трактующие C:Windows как системный каталог, Оба размещения должны быть проверены, если вам нужно отыскать инсталлированноrо клиента.

(обратно)

15

Точность задает количество значащих цифр (игнорируя конечные или начальные нули), которое может храниться в типе данных без переполнения или потери данных.

(обратно)

16

Хранимыми типами являются SMALLINT, INTEGER или BIGINT в зависимости от объявлен-

(обратно)

17

Использование «!=» в качестве замены для «<>» допустимо в Firebird, но не соответствует стандарту. Те, у кого хорошее экстрасенсорное восприятие, будут придерживаться «о», чтобы сделать код более удобным для чтения.

(обратно)

18

Часто таблица RDB$DATABASE используется для «пустых» запросов, которые возвращают одно вычисляемое значение или контекстную переменную. Это реальная системная таблица, содержащая одну и только одну строку. Она используется как DUAL В Oracle.

(обратно)

19

Несмотря на то, что в третьем диалекте генераторы являются числами BIGINT, совершенно необязательно столбец первичного ключа, для которого будет применяться генератор, также делать BIGINT. При выборе типа данных для столбца первичного ключа следует учитывать конкретные нужды предметной области. Как правило, в большинстве случаев вполне достаточно INTEGER. — Прим. науч. ред.

(обратно)

20

Существуют техники для поддержки непрерывных последовательностей с использованием генераторов, которые могут быть реализованы в случае абсолютной необходимости повторного применения неиспользуемых промежутков в сериях, не являющихся значениями ключа. Список Tech Info «Контролируемые серии чисел» (An Auditable Series of Numbers) описывает подобную технику на http://www.ibobjects.com/TechInfo.html.

(обратно)

21

Хранится в системной таблице RDB$FIELDS как RDB$FIELD_PRECISION.

(обратно)

22

Хранится в системной таблице RDB$FIELDS как RDB$FIELD_SCALE.

(обратно)

23

Спасибо Джеффу Ворбойзу (Geoff Worboys) за его понятные замечания по этой больной теме.

(обратно)

24

Так в оригинале. В документации по InterBase указан диапазон дат от 1 января 100 г. до 29 февраля 32 768 г. — Прим. перев.

(обратно)

25

Для того чтобы осуществлять агрегацию интервала (суммирование, среднее), необходимо хранить не время окончания интервала, а его длительность, например в секундах, в обычном целочисленном типе данных. — Прим. науч. ред.

(обратно)

26

Вероятно, не будет ошибкой, если эта дата дает целое значение, называемое Измененным юлианским номером дня. Подробности см. на http://hermetic.nofadz.com/cal_stud/jdn.htm.

(обратно)

27

API предоставляет программистам две полезные функции для преобразования структуры дата/время клиентского языка в формат Firebird и из формата Firebird. См. в документе фирмы Borland «API Guide» (Руководство по API) описание функций isc_encode_date() и isc_decode_date().

(обратно)

28

Тип BLOB не является волшебной палочкой для сохранения и поиска больших объемов файлов двоичных данных. Иногда при учете производительности накладные расходы и неуправляемость хранения нединамических объектов данных, вроде фильмов или звуков, в базе данных перевешивает преимущества, которые вы предполагали. Хранение ссылок на объекты файловой системы может быть хорошим решением.

(обратно)

29

Возможна передача строковых типов как входных данных для BLOB С предоставлением серверу возможности их конвертирования. При этих условиях невозможно хранение BLOB, который превышает ограничение для строк в 32 Кбайта.

(обратно)

30

Чтобы понять эти тонкости, обратитесь к разд. «Темы оптимизации» главы 18.

(обратно)

31

При изменении типов домена учитывайте, что в хранимых данных могут быть данные, которые не пройдут преобразование из одного типа в другой. Например, VARCHAR В INTEGER сконвертируется, только если VARCHAR будет содержать цифры и числа, допустимые для INTEGER — Прим. науч. ред.

(обратно)

32

Существует море литературы, содержащей описания техник эффективного анализа задач бизнеса для проектировщика реляционных баз данных, размышления об уровне нашей профессиональности. Автор особенно рекомендует Data Modeling Essentials: Analysis, Design and Innovation, 2nd Edition by Graeme C. Simsion (Coriolis, 2000).

(обратно)

33

Команда SET TERM не является SQL-оператором, понимаемым Firebird. Это команда утилиты 1SQL, позволяющая задать индикатор окончания оператора DDL. SET TERM используется только там, где инструмент разработчика может выполнить несколько команд DDL и DML в одном скрипте. — Прим. науч. ред.

(обратно)

34

Замечание для программистов API. В динамическом SQL (DSQL) оператор CREATE DATABASE или CREATE SCHEMA должен быть выполнен с EXECUTE IMMEDIATE. Дескриптор базы данных и имя транзакции, если присутствуют, должны быть инициализированы нулем до использования.

(обратно)

35

Для «русскоязычных программ» следует использовать набор символов WIN1251.- Прим. перев.

(обратно)

36

При создании или расширении многофайловой базы данных для всех файлов базы данных используйте либо только LENGTH (явную длину конкретного файла), либо только STARTING AT (указание начала нового файла), для избежания путаницы. — Прим. науч. ред.

(обратно)

37

Сервис API предоставляет доступ к обоим методам для перевода базы данных в режим только для чтения. Чтобы получить информацию, изучите доступную документацию по различным группам параметров действий сервиса (isc_action_svc_xxx), которые могут передаваться в функцию isc_service_start О . Множество компонентов доступа к базе данных реализуют эти функции для использования в различных языковых средах.

(обратно)

38

К сожалению, теневое копирование не обеспечивает восстановление, если база данных была случайно удалена оператором DROP DATABASE. Когда вы удаляете таким образом базу данных, ее теневая копия (shadow) также удаляется.

(обратно)

39

Для автора оказалось невозможным найти кого-нибудь, кто мог бы объяснить преимущества (если они существуют) ведения множества наборов теневых копий. Система нумерации могла быть результатом некоторой функциональности, которая никогда не была реализована. При отсутствии лучшей информации, похоже, имеет смысл остановиться на одном наборе

(обратно)

40

CONDITIONAL SHADOW на самом деле имеет смысл как дополнение к AUTO, и только. Если CONDITIONAL создана как второй набор по отношению к AUTO, то она будет пустой до тех пор, пока с базой или с AUTO SHADOW не произойдет сбой. При сбое CONDITIONAL SHADOW будет наполнена страницами из целого файла и примет на себя функции альтернативной копии, таким образом даже в случае сбоя дисковой системы будет существовать две копии базы данных. И, разумеется, CONDITIONAL SHADOW не имеет смысла как дополнение к manual shadow (как и комбинация из двух SHADOW- AUTO + MANUAL), Т. к. при MANUAL в случае сбоя работа сервера с базой останавливается. — Прим. науч. ред.

(обратно)

41

Если вы кодируете CREATE TABLE в приложении встроенного SQL (Embedded SQL) с намерением также в этом приложении заполнять данными эту таблицу, то таблица вначале должна быть объявлена в предшествующем операторе DECLARE TABLE.

(обратно)

42

Если ваша операционная система поддерживает использование многобайтовых символов в именах пользователей или вы используете многобайтовый набор символов при определении ролей, то каждый столбец, в котором будут сохраняться в качестве значений по умолчанию CURRENT_USER или CURRENT_ROLE, должен быть определен с использованием совместимого набора символов.

(обратно)

43

См. ограничение NOT NULL для столбца, NULL может оказаться несовместимым значением

(обратно)

44

Здесь мы говорим об архитектуре Intel. Выравнивание может отличаться в некоторых архитектурах.

(обратно)

45

Создание спецификаций для чтения/записи во внешний файл может потребовать гораздо больше детальных знаний о формате, чем здесь обсуждается. Наборы символов и размеры в байтах могут оказаться проблемой. Во многих случаях использование в качестве набора символов нейтрального набора символов OCTETS в определении внешней таблицы может решить некоторые проблемы. Импорт и экспорт данных не подчиняется принципу «один размер подходит всем».

(обратно)

46

Внешний файл должен быть освобожден, когда завершатся выполняющиеся с ним операции. Для сервера некорректно оставлять его заблокированным, поскольку внешние данные не менялись. Это программная ошибка, по поводу которой читатель может запросить исправле-

(обратно)

47

При этом существует одно исключение. Индекс внешнего ключа с очень низкой селективностью — высочайший уровень дублирования небольшого количества значений в таблице — может оказать серьезное влияние на производительность, если его ключевые столбцы формируют условие соединения.

(обратно)

48

Толковое добавление к этому в книге Data Modeling Essentials, 2nd Edition by Graeme Simsion (Coriolis, 2000).

(обратно)

49

Действие NO ACTION иногда называют «ограниченным» действием.

(обратно)

50

Не следует полагаться на триггерную ссылочную целостность потому, что ограничения PRIMARY KEY, FOREIGN KEY и UNIQUE работают вне контекста транзакций (т. е. «видят» все версии записей), а пользовательские триггеры — в контексте пользовательских транзакций. В результате пользовательский триггер, проверяющий наличие определенной записи, никоим образом не узнает, что эта запись на самом деле уже удалена или изменена в другой, конкурирующей, транзакции. -Прим. науч. ред.

(обратно)

51

И надеяться, что эта маленькая причуда оптимизатора с ключами один-к-одному будет разрешена в следующих релизах.

(обратно)

52

В случаях, когда условие поиска задает LIKE ‘ string% ‘, оптимизатор обычно преобразовывает его к предикату STARTING WITH 1 string1 и использует индекс, если он доступен.

(обратно)

53

Составные индексы не являются столь важными в Firebird, как в большинстве других СУБД. Часто их использование является неоправданным, потому что Firebird интеллектуально использует индексы из одного столбца.

(обратно)

54

В Firebird и InterBase индексы не могут быть «разбалансированы». -Прим. науч. ред.

(обратно)

55

На самом деле индексы в Firebird и Interbase никогда не бывают «разбалансированными», т. е. глубина индекса всегда постоянна для всех листовых страниц. Соответственно, перестраивать индекс имеет смысл, когда он поврежден и когда требуется высокая скорость массовых вставок, удалений или обновлений. В реальных и больших базах данных плотность заполнения страниц индекса не опускается ниже 85%, независимо от числа дубликатов ключей. — Прим. науч. ред.

(обратно)

56

Изложенное понятие селективности обратно числам, реально используемым оптимизатором. Оптимизатор берет информацию о селективности из столбца RDB$STMTSTICS таблицы RDB$INDICES, который вычисляется по формуле 1/(число ключей — число повторяющихся ключей). Чем меньше это число, тем выше селективность индекса и тем полезнее он с точки зрения оптимизатора. Для уникальных индексов селективность стремится к нулю (зависит от числа ключей). Для неуникальных индексов худшим случаем является селективность, равная 1, когда все значения ключей идентичны. — Прим. науч. ред.

(обратно)

57

На оптимизатор в основном влияет то, что с течением времени если индекс меняется (меняются индексируемые данные), то статистика индекса остается неизменной, т. к. она меняется только вручную вызовом оператора SET STATISTICS. Поэтому вместо рекомендуемого здесь периодического пересоздания индексов лучше озаботиться регулярным пересчетом статистики индексов. — Прим. науч. ред.

(обратно)

58

В этом месте разговор идет со слов Ann Harrison, «матери InterBase».

(обратно)

59

Сборка мусора в больших цепочках дубликатов ключей значительно ускорена в Firebird 2.0. Собственно, в Firebird 2.0 изменена структура индексов. — Прим. науч. ред.

(обратно)

60

IBOConsole поддерживает Lorenzo Mengoni — см. http://www.mengoni.it.

(обратно)

61

Это неверно, и автор подтвердил ошибку. Next transaction не имеет никакой связи со sweep. Автоматический sweep стартует, когда разница между Oldest Snapshot и Oldest Interesting больше Sweep interval (в Firebird 2.0 за верхнюю границу берется не Oldest Snapshot, a Oldest Active). -Прим. науч. ред.

(обратно)

62

Американцы предпочитают говорить «сиквел». -Прим. перев.

(обратно)

63

Рекомендую обратиться на http://www.interbase-world.com. Там можно найти перевод на русский язык некоторых книг из документации фирмы Borland по InterBase 7.1. — Прим. пе-

(обратно)

64

В переводе на русский язык книга называется М. Грабер «SQL» и доступна в книжных магазинах начиная с 2001 г. — Прим. науч. ред.

(обратно)

65

Фактически синтаксис именованного курсора доступен как «скрытая возможность» и в PSQL, хотя он не полностью реализован в Firebird 1.5. Синтаксис был расширен после версии 1.5 и должен появиться в последующих релизах.

(обратно)

66

Более подробную информацию см. в Embedded SQL Guide (EmbedSQL.pdf) в документации по InterBase 6.0, опубликованной Borland.

(обратно)

67

Программисты прямого API и разработчики компонентов интерфейса могут получить больше информации из InterBase API Guide (APIGuide.pdf) в документации по InterBase 6.0, опубликованной Borland.

(обратно)

68

Поскольку выходной набор DISTINCT предполагает существование дубликатов, чтобы обеспечить уникальность потока поиска для индивидуального изменения, нельзя полагаться на его поля. Некоторые средства разработки явно трактуют выходные наборы, полученные от запросов DISTINCT как неизменяемые.

(обратно)

69

В InterBase 6.5 и выше вместо FIRST используется ключевое слово ROWS, следующее за ORDER BY. Этот же синтаксис может быть использован и в Firebird 2.0. Подробнее о синтаксисе ROWS см. В документации по InterBase 7.x — Прим. науч. ред.

(обратно)

70

FIRST и SKIP всего лишь ограничивают количество записей, выдаваемых клиенту. Запрос вне зависимости от наличия или отсутствия FIRST и SKIP всегда будет выполнен целиком. — Прим. науч. ред.

(обратно)

71

Если два набора, объединяемых UNION, принципиально не будут содержать дубликатов строк, необходимо использовать UNION ALL, чтобы сервер не занимался зря работой по удалению несуществующих дубликатов строк. — Прим. науч. ред.

(обратно)

72

Это «ускоренное» вычисление логических значений, которое реализовано в Firebird 1.5 и выше. Firebird l.Ojc использует полное логическое вычисление. Для тех, кто любит изобретательные загадочные выражения, старый метод может быть восстановлен при использовании параметра конфигурации FullBooleanEvaluation.

(обратно)

73

Операторы сравнения Firebird поддерживают сравнение значения левой части с результатом скалярного подзапроса (встроенного запроса) в правой части оператора. Подробности см. в разд. «Запросы существования» позже в этой главе и в обсуждении подзапросов в следующей главе.

(обратно)

74

Для русского языка обычно используется кодировка WIN 1251, и два варианта COLLATE — WIN 1251 (по умолчанию), и PXWCYRL. За особенностями использования вариантов COLLATE, и кодировками и сортировками для других языков (в том числе стран СНГ) обратитесь к ReleaseNotes. — Прим. науч. ред.

(обратно)

75

Firebird 1.0.x выполняет полные логические вычисления. Сокращенное вычисление булевых выражений в более поздних версиях может быть отключено на уровне сервера при установке параметра конфигурации CompieteBooleanEvaluation. Подробности см. в главе 3.

(обратно)

76

До Firebird 1.5 функция UPPER работала только для столбцов COLLATE PXW_CYRL (или при явном указании для конкретного столбца). В Firebird 1.5 таблица перекодировки символов в верхний регистр есть и в «умолчательном» COLLATE WIN1251. — Прим. науч. ред.

(обратно)

77

Программная логика в комбинации с техниками DSQL, описываемые в данной главе, могут быть использованы в модулях PSQL, которые возвращают клиентам виртуальные таблицы, а также в других модулях PSQL. См. часть VII. Просмотры, рассматриваемые в главе 24, обеспечивают другие способы получения наборов данных из нескольких таблиц.

(обратно)

78

Ключевое слово OUTER для всех случаев является необязательным. —

(обратно)

79

В «SQL for Smarties» Joe Celco предлагает интересные решения для хранения и поддержки древовидных структур в реляционных базах данных (Morgan Kaufmann, 1999).

(обратно)

80

Многие аспекты плана, сконструированного внутренне оптимизатором, не видны в плане, показанном в isql и недоступны через синтаксис предложения PLAN для пользовательских планов. Синтаксис показывает только подмножество реального плана, которому будет следовать сервер при выполнении запроса.

(обратно)

81

Поскольку база данных примера не имеет таблиц без индексов, некоторые примеры в этом разделе используют специально описанные неиндексированные версии таблиц EMPLOYEE, PROJECT и DEPARTMENT, названные EMPLOYEE1, PROJECT1 и Departments соответственно. Скрипт с именем NO_INDEXES.SQL для создания этих таблиц может быт загружен с http://www.apress.com.

(обратно)

82

Другой причиной использования алиасов при задании запросов и планов является то, что, скорее всего, подобная согласованность будет поддерживаться в следующих версиях Firebird.

(обратно)

83

«Сортировка по индексу» является недоразумением. Предложение ORDER В плане запроса дает указания серверу читать поток вне порядка хранения (то есть с использованием навигационного индекса для поиска строк). Этот метод может работать только с управлением потоком в цикле и создавать предварительно упорядоченный результат. Поскольку ORDER может быть использован только для левого потока в соединении, любое правило, которое влияет на упорядоченность соединения — например, внешнее соединение, которое не дает возможность потоку быть самым левым — будет иметь преимущество.

(обратно)

84

Оптимизатор InterBase, Firebird 1.0 и 1.5 считает составные индексы более селективными, чем они есть на самом деле. В этом виновата особенность подсчета селективности, которая производится целиком для всего ключа. В Firebird 2.0 селективность составных индексов учитывается отдельно по каждому сегменту составного ключа, что позволяет избежать сильных проколов в оптимизации запросов. — Прим. науч. ред.

(обратно)

85

Подобное дополнительное условие может привести к тому, что вообще никакие индексы не будут использоваться. Более правильным в случае множества условий поиска является «отключение» низкоселективного индекса для отдельного столбца путем превращения условия сравнения в вычисляемое: для числовых столбцов — where field+0 = value, для строковых — where field || » = value. — Прим. науч. ред.

(обратно)

86

В этом случае также желателен и триггер BEFORE UPDATE. — Прим. перев.

(обратно)

87

Theo Haerder and Andreas Reuter, «Principles of Transaction-Oriented Database Recovery», ACM Computing Surveys 15(4) (1983): 287-317.

(обратно)

88

Andreas Reuter and Jim Gray, Transaction Processing Concepts and Techniques (San Francisco, С A: Morgan Kaufmann, 1993).

(обратно)

89

Программисты API. смотрите в TP В константу isc_tpb_no_auto_undo.

(обратно)

90

Спасибо, Ann Harrison!

(обратно)

91

В оригинале не совсем верно выбраны термины. Никакой «таблицы», конечно, нет. Есть битовый массив, который меняется при изменении состояния транзакций и который копируется в память (частично) при старте транзакций SNAPSHOT. Также TIP не может быть «раздут», поскольку битовый массив просто растет в размерах при старте каждой новой транзакции и строится заново при очередном восстановлении (restore). Размер TIP равен Next Transaction / 4 (в байтах). — Прим. науч. ред.

(обратно)

92

Здесь и далее в тексте практически не упоминается важный параметр Oldest Snapshot Transaction (OS Г). — Прим, науч. ред.

(обратно)

93

Хорошо понимать цикл жизни транзакций в Firebird, если вы работаете и с другими реляционными СУБД, например, с PostgreSQL, которая имитирует многоверсионную архитектуру Firebird.

(обратно)

94

Во всех версиях Firebird и в InterBase до версии 7.1 sweep срабатывает, когда расстояние между OIT и Oldest Snapshot Transaction (а не OAT) становится больше sweep interval (см. разд. «Другие переключатели gstat» главы 18). В Firebird 2.0 срабатывание sweep будет зависеть именно от разницы OAT-OIT. — Прим. науч. ред.

(обратно)

95

OST — это на самом деле номер транзакции, которая была активной на момент старта OAT. — Прим. науч. ред.

(обратно)

96

Возможно, здесь имеются в виду внешние ключи с опцией ON UPDATE/DELETE CASCADE. В этом случае при изменении мастер-записи автоматически модифицируются записи-детали. Ни в каких других случаях «зависимые» таблицы не обновляются сервером. — Прим. науч. ред.

(обратно)

97

Ничто не запрещает завершить транзакцию по COMMIT, независимо от успеха или неуспеха выполнения в ней операторов. Разумеется, именно в обработчиках исключений вызывать COMMIT действительно не рекомендуется. — Прим. науч. ред.

(обратно)

98

Для энтузиастов Borland опубликовал документ «Embedded SQL Guide» (Руководство по встраиваемому SQL) как часть комплекта документации по InterBase. Версии этого тома также доступны в формате PDF на некоторых сайтах — найдите через Google «EmbedSQL.pdf».

(обратно)

99

То же, «API Guide» (Руководство по API). APlGuide.pdf.

(обратно)

100

SET TRANSACTION, как COMMIT и ROLLBACK, не является оператором, выполняемым на сервере. Будучи оператором Embedded SQL он преобразуется утилитой gpre (или isql) в вызовы Firebird API (isc_start_transaction…). — Прим. науч. ред.

(обратно)

101

Для большинства этих реализаций была выполнена трансляция заголовочного файла С Firebird в соответствующий язык высокого уровня для предоставления средств API Firebird (или InterBase) для этого языка. Если вы планируете разрабатывать программы с использованием API, хорошим решением будет поиск в Интернете существующих трансляций заголовочного файла.

(обратно)

102

Фактически существуют две различные функции для запуска транзакции: isc_start_ transaction() используется в языках, которые поддерживают передачу переменного количества аргументов при вызове функций; isc_start_multiple() используется в языках, требующих статический список аргументов. isc_start_transaction() ограничивается одной транзакцией, которая может использовать до 16 баз данных, в то время как isc_start_multiple О запускает транзакции, обращающиеся к большему количеству баз данных или обращающиеся к переменному количеству баз данных, которое может превышать 16.

(обратно)

103

Тип isc_tr_handle является указателем void, определенным в заголовочном файле ibase.h, который расположен в каталоге /include в каталоге вашей инсталляции Firebird.

(обратно)

104

Если в будущем структура TPB изменится, эта константа также будет изменена, так что сервер легко сможет обрабатывать клиентов, скомпилированных в друrой версии.

(обратно)

105

Неанглийские версии файла сообщений не были доступны во время написания данной книги. Готовятся проекты трансляции. Если вас интересует локализованный файл сообщений, обратитесь к спискам сообщества Firebird. Сообщите, что вы заинтересованы в участии в проектах локализации!

(обратно)

106

Существует несколько неприятных исключений из этого правила. Например, ISC ERROR CODE: 335544321 «Arithmetic exception, numeric overflow, or string truncation» (Арифметическое исключение, числовое переполнение или усечение строки) объединяет такой широкий диапазон возможностей, что оно обычно вызывает состояние изумления даже у программиста, который допустил возможность появления такого исключения.

(обратно)

107

Если клиентская библиотека удаленного клиента находит локальную копию файла сообщений в известном «корневом» каталоге, Firebird 1.5 будет использовать именно ее и перекроет этот файл в каталоге сервера RootDirectory. Поскольку до сих пор не решено, является ли это желательной возможностью, то может быть разумным устранить зависимость от такого поведения в интересах будущей защиты. В любом случае файловые системы рабочих станций являются весьма уязвимыми при неправильном поведении пользователя.

(обратно)

108

По причине ограничения объема книги тема именованных курсоров затрагивается лишь слегка. Для работы с ними API предоставляет группу функций isc_dsql_*. Синтаксис оператора DECLARE CURSOR, полностью реализованный в ESQL, доступен в некоторых средах программирования DSQL. Описание использования именованных курсоров в модулях PSQL см. в главах 29 и 30.

(обратно)

109

Инструмент IBAnalyst (см. www.ibase.ru) выдаст все возможные предупреждения и рекомендации по поводу состояния транзакций на сервере. — Прим. науч. ред.

(обратно)

110

Выполнение backup никак не влияет на Transaction Inventory Page, a sweep может продвинуть вперед OIT, но не более того. — Прим. науч. ред.

(обратно)

111

В версии 1.5 возможна передача оператора DDL в строке EXECUTE STATEMENT. Делайте это только в особых случаях.

(обратно)

112

Только в отношении работы конкретного запроса SQL, выполненного из клиентского приложения, в «недрах» которого произошла ошибка. Работа, выполненная ранее другими запросами SQL в этой же транзакции, будет сохранена (если транзакция завершится по commit). — Прим. науч. ред.

(обратно)

113

Начиная с версии 1.5. существует возможность объединять несколько событий в одном триггере. Подробности см. в главе 31.

(обратно)

114

В версии 1.5 LEAVE заменяет недокументированный оператор BREAK, который был частично реализован в версии 1.0.x. Не используйте BREAK.

(обратно)

115

Эта процедура является очень скромным примером программирования в PSQL. В SQL существует лучший способ проверить существование строк, чем их подсчет. В главе 32 мы снова будем обсуждать эту процедуру, выполнив некоторые изменения в ней, чтобы показать это. Если вы посмотрите исходные коды процедуры в базе данных, вы также заметите, что операторы SUSPEND и EXIT щедро разбросаны в разных местах, где они не нужны. Операторы SUSPEND и EXIT имеют идентичное использование в выполняемой процедуре. При этом в процедурах выбора оператор SUSPEND применяется особо. Для ясности и эффективности документирования предпочтительно исключить использование SUSPEND в качестве синонима EXIT.

(обратно)

116

ESQL, «супермножество» DSQL, имеет небольшое отличие в синтаксисе предложения INTO. Там INTO помещается сразу после ключевого слова SELECT и квантификатора строки (если присутствует). Водворение INTO В конец оператора в PSQL позволяет использовать наборы UNION В качестве входа для курсоров PSQL.

(обратно)

117

В Firebird 1.5 работа, выполняемая в данной вложенной процедуре, может быть реализована с помощью выражения CASE. Подробности см. в главе 21.

(обратно)

118

Клавдио Валдеррама (Claudio Valderrama) провел исследования по RDB$DB_KEY, именно его примеры здесь используются. Он живет в Чили, его псевдоним «robocop». Клавдио является официальным инспектором кода в проекте Firebird. Он поддерживает обширный сборник статей и кодов для Firebird и InterBase на своем сайте: http://www.cvalde.net.

(обратно)

119

Хотя триггеры «привязаны» к таблицам, некоторые инструменты выводят общий список триггеров для просмотра, сортируя его по именам триггеров. В этом случае следует выбрать иной способ формирования имени триггера (из имени таблицы, его типа и других характеристик), чтобы представление триггеров было отсортировано в нужном вам порядке. — Прим.

(обратно)

120

NEW.* и OLD.* также допустимы в DDL для ограничений CHECK на уровне таблицы — например, CREATE TABLE BLAH (ID INTEGER, DATA INTEGER, CONSTRAINT CHECK_INCR CHECK(NEW.DATA > OLD.DATA)).

(обратно)

121

В Firebird 2.0 модификация значений OLD. * явно запрещена и будет вызывать ошибку при попытке присвоения значений переменным OLL. * как при выполнении, так и при создании триггера, Также запрещена модификация значений NEW, * В триггерах AFТER. Прuм. науч. ред.

(обратно)

122

Некоторые компоненты интерфейса предоставляют методы или свойства для автоматического выполнения этой маленькой задачи.

(обратно)

123

Такая манипуляция будет гораздо более простой, если использовать внешнюю функцию для вычисления длины преобразованного целого числа. Я выбираю — может быть немного с другой точки зрения — демонстрацию того, что можно выполнить манипуляцию строками без использования внешних функций.

(обратно)

124

Поскольку проверки Foreign Key (FK) выполняются вне транзакций, а пользовательские триггеры работают всегда в контексте транзакций, полноценно заменить FK триггерами невозможно — из-за ограничений «видимости» триггер будет видеть старые данные, которые уже изменены. Приведенная схема будет работать, только если для справочной таблицы наложен ряд ограничений по удалению и изменению записей. — Прим. науч. ред.

(обратно)

125

Проектирование древовидных структур в реляционных базах данных само по себе является наукой. Будучи очаровательным, это все же выходит за пределы данного руководства. Найдите в Интернете написанную Joe Celko книгу на эту тему: Joe Celko’s Trees and Hierarchies in SQL for Smarties (Morgan Kaufmann, 2004).

(обратно)

126

Ряд очень полезных статей по реализации древовидных структур в РСУБД вы сможете найти в соответствующем разделе страницы www.ibase.ru/develop.htm. — Прим. науч. ред.

(обратно)

127

Как показывает практика, такие переводы не приносят ожидаемой пользы разработчикам. Сообщения сервера ориентированы на разработчика приложений, и даже будучи переведенными, слишком сложны для восприятия пользователем программы. Более грамотным является корректная обработка ошибок, возникающих на сервере, в коде клиентского приложения, и выдача пользователю осмысленных и понятных сообщений в контексте прикладной области. Не составляет сложености в это же время сохранять исходные сообщения от сервера в специальном файле для последующего анализа корректности работы приложения — Прим. науч. ред.

(обратно)

128

См. APIGuide.pdf в комплекте документации по InterBase, опубликованной Borland Software Inc.

(обратно)

129

He следует путать с компонентами-обработчиками сообщений, которые инкапсулируют на клиентской стороне механизм событий.

(обратно)

130

Ресурс ibsurgeon.com предлагает не только средства ремонта баз данных, но с августа 2005 года и средство для восстановления поврежденных резервных копий баз данных. — Прим. науч. ред.

(обратно)

131

См. http://security.ucdavis.edu/HardenWin2Klab.pdf

(обратно)

132

Windows 2000 Security Handbook (Osborne-McGraw Hill, 2000) написана Philip Сох и Tom Sheldon.

Биографию Philip Сох см. на http://www.systemexperts.com/bios.html.

(обратно)

133

Известным продуктом для шифрования сетевого трафика для Windows и Linux является ZeBeDee (www.ibase.ru/devinfo/zebedee.htm). -Прим. науч. ред.

(обратно)

134

По соображениям безопасности системы не должны поставляться вместе с библиотекой встроенного сервера, доступной для активного сервера Firebird, если только корневой каталог Firebird не защищен жестко от неавторизованных посетителей. Подробности см. ранее в главе

(обратно)

135

Несмотря на это в Firebird используется шифрование с потерей данных, которое не позволяет восстановить исходный пароль путем дешифрования. В Firebird 2.0 вместо DES используется MD5. — Прим. науч. ред.

(обратно)

136

Как уже говорилось ранее, шифрование пароля производится с потерей данных. Единственный способ, которым можно «взломать» пароль, — это перебор словаря, шифруемого тем же алгоритмом, что используется в Firebird. В данном случае время подбора существенно сокращается тем, что шифруемый пароль имеет длину не более 8 символов. — Прим. науч. ред.

(обратно)

137

Сервер просто не проверяет никакие права доступа для пользователя SYSDBA. В частности, поэтому операции над множеством объектов в SQL производятся от имени SYSDBA чуть быстрее, чем от имени других пользователей. — Прим. науч. ред.

(обратно)

138

Все версии InterBase и Firebird имеют весьма своеобразное поведение: если выдан GRANT на UPDATE к столбцам явно, то успешно может быть выполнен только UPDATE всей таблицы, без указания ограничения WHERE. Таким образом, выдача GRANT на UPDATE к конкретным столбцам является совершенно бесполезной. -Прим. науч. ред.

(обратно)

139

По причине ошибки в Windows использование DummyPacketlnterval может привести к зависанию или краху Windows на клиентской стороне. Объяснения см. в статье Microsoft Support: http://support.microsoft.com/default.aspx?kbid=296265. Не рекомендуется его также использовать и для систем, отличных от Windows, поскольку это может привести к отключению активного клиента.

(обратно)

140

Подробно по настройкам keepalive читайте статью www.ibase.ru/devinfo/keepalive.htm. — Прим. науч. ред.

(обратно)

141

Возможно, здесь ошибка — включение TCPJTODELAY как раз означает отключение алгоритма Nagle, то есть выключение режима буферизации данных при пересылке, чему соответствует установка параметра no_nagle в True. — Прим. науч. ред.

(обратно)

142

Здесь речь идет о порядке обработки параметров в запросах с подзапросами, содержащих параметры как во внешней части запроса, так и в подзапросе. В старых версиях InterBase и Firebird параметры заполнялись сначала для внешнего запроса, а потом для подзапроса, хотя по тексту запроса они располагаются наоборот. — Прим. науч. ред.

(обратно)

143

Общая библиотека UDF доступна на нескольких сайтах, включая http://www.ibphoenix.com.

(обратно)

144

В терминах C++ «по указателю».

(обратно)

145

Определена в ibase.h как blobcallback (структурный тип) и BLOBCALLBACK (указатель на структурный тип). Это объявление дает полное определение для функций чтения/записи указателей, которые упрощают использование их в современных компиляторах. См. также примечания перед объявлением в ibase.h.

(обратно)

146

При отсутствии ограничений на размещение внешних таблиц уже давно известны возможности использовать внешние таблицы как для перекачивания базы данных с сервера на клиент, так и для внедрения с клиента на сервер вредоносных UDF. — Прим. науч. ред.

(обратно)

147

SET NAMES, то есть набор символов соединения, должен быть задан до подсоединения к базе данных.

(обратно)

148

Вопросы безопасности файловой системы и других средств окружения обсуждаются в главах 33 и 34.

(обратно)

149

Если вы по-настоящему беспечны и оставите эти переменные окружения на рабочих станциях, показывая всему миру пароль пользователя SYSDBA, удаленные пользователи также смогут выполнять копирование, не задавая учетных данных. Нечего и говорить, что такая практика должна быть полностью исключена.

(обратно)

150

В некоторых случаях администраторы БД перенаправляют вывод gbak в утилиты упаковки, такие как gzip. Это позволяет «на лету» получить запакованную резервную копию базы данных с меньшей нагрузкой на диск в процессе создания или восстановления резервной копии. — Прим. науч. ред.

(обратно)

151

Информацию о стандарте XDR можно найти на http://asg.web.cmu.edu/rfc/rfcl832.html.

(обратно)

152

Будьте внимательны, -k обеспечивает не только восстановление БД без shadow, но и удаление существующих shadow с именами, сохраненными в файле резервной копии. Этот баг исправлен только в Firebird 2.0 (см. баг № 1122344 в багтрекере проекта Firebird: sf.net/projects/firebird). — Прим. науч. ред.

(обратно)

153

Это справедливо для InterBase 7.1/7.5 и Firebird 2.0. Для всех предыдущих версий InterBase и Firebird «зазор», выше которого стартует автоматический sweep, определяется как разница между OIT и OST (Oldest snapshot). — Прим. науч. ред.

(обратно)

154

После того как база данных переведена в состояние shutdown, к ней могут подключиться только пользователи SYSDBA и владелец базы данных (owner). Всем другим пользователям при попытке соединения с такой базой данных будет выдано соответствующее сообщение об ошибке. — Прим. науч. ред.

(обратно)

155

Количество соединений SYSDBA при состоянии базы данных shutdown ничем не ограничено. Только в Firebird 2.0 есть режим монопольноrо (только одноrо) подсоединения SYSDBA — Прuм, науч, ред.

(обратно)

156

Суффикс .gdb включен в filelist.xml, в список файлов, к которым применяется системное восстановление, располагающихся в каталоге Windows/System. К сожалению, из списка типы файлов не могут быть удалены. Это действует на базы данных Firebird, имеющие расширение gdb — системное восстановление приводит к замедлению начального соединения с подобными базами данных, и бывает, что это приводит к разрушению данных (подтвержденные

(обратно)

157

Информацию по ремонту баз данных можно найти здесь: http://www.ibase.ru/dbrepair.htrn и http://www.ibase.ru/devinfo/db_repair.htm. — Прим. науч. ред.

(обратно)

158

Для понимания темы Lock Print с благодарностью и признательностью отправляемся к Ann Harrison. Она была первой, кто подробно документировал этот полезный, но слабо освещенный инструмент поиска неисправностей, в официальном документе, написанный Ann для IBPhoenix. «Reading a Lock Print» можно найти в разделе документации на http://www.ibphoenix.com.

(обратно)

159

Самый последний вариант библиотеки FreeUDFLib с исправленными функциями BLOB находится на www.ibase.ru. — Прим. науч. ред.

(обратно)

160

Большинство современных приложений, в том числе офисных, требуют совместимости драйвера со спецификацией ODBC 3.5. Альтернативные драйверы ODBC также можно найти на www.ibase.ru. — Прим. науч. ред.

(обратно)

161

Кроме драйверов ODBC еще существуют драйверы OLEDB. Великолепный драйвер, который можно использовать из офисных приложений, Visual C++ и других инструментов, создан в Липецке: http://www.ibprovider.com/rus/index.htmI. — Прим. науч. ред.

(обратно)

162

Для получения этого драйвера обратитесь с запросом на адрес sales@ibase.ru. — Прим.

(обратно)

163

На момент перевода это версия 6.25. — Прим. перев.

(обратно)

164

Yaffil является ответвлением Firebird для Windows. Он был создан с открытыми кодами в конце 2003 года и затем был включен в коды Firebird 2.

(обратно)

165

Тем не менее на текущий момент практически никаких проблем при использовании IBX с Firebird 1.0, 1.5 и 2.0 нет. -Прим. науч. ред.

(обратно)

166

Во время написания этой книги автор услышала о первом случае нового способа разрушения баз данных. Жертва проигнорировала все советы и разместила базу данных в каталоге NFS. После этого продолжалось соединение клиентов с базой данных клиентов через два Классических сервера Firebird 1.5 с различных машин, ни одна из которых не была владельцем жесткого диска, на котором находилась база данных. В результате база данных была разру-

(обратно)

167

Полная коммерческая версия IBExpert бесплатна для использования в России и странах СНГ, там где в качестве кодировки по умолчанию для операционной системы Windows установлена таблица символов 1251. -Прим. науч. ред.

(обратно)

168

А также на сайте www.ibase.ru. — Прим. науч. ред.

(обратно)

169

На самом деле, как показывает практика, не более 16 000 столбцов INTEGER.- Прим. науч. ред.

(обратно)

170

Мало какие нынешние приложения переживут 19 января 2038 года — это проблема переполнения даты еще более худшая, чем проблема 2000 года. Устаревший формат даты в языке С (структура time t) не способен хранить года более 2038. С другой стороны, так долго приложения не эксплуатируются, а для внедряемой сейчас 64-битовой архитектуры и новых приложений такой проблемы нет. — Прим. науч. ред.

(обратно)

171

3 Это число больше реального числа, которое способна обеспечить операционная система. Например, RedHat Linux без изменения настроек и перекомпиляции ядра допускает до -600 соединений. Чаще всего проблема с числом соединений возникает из за «несконфигурированного» xinetd на Linux, где по умолчанию задано ограничение в -50-60 соединений на конкретное приложение. — Прим. науч. ред.

(обратно)

172

Реальное физическое ограничение на объем одной таблицы — 36.7 Гбайт. Это примерно 600 миллионов записей, состоящих из двух INTEGER Ограничение связано с внутренним 32-разрядным идентификатором. В Firebird 2.0 это ограничение устранено (используются 64(40)-битовые идентификаторы). — Прим. науч. ред.

(обратно)

173

В Firebird 2.0 максимальный размер ключа индекса- 1/4 размера страницы. Например, для страницы 4 Кбайт это 1024 байт. — Прим. науч. ред.

(обратно)

174

Полный комплект документации по InterBase 7.5 (на английском языке) поставляется только в электронном виде в составе серверной лицензии. Эти книги можно приобрести в печатном виде только поштучно ($25 за книгу). На русском языке существует только печатная документация по InterBase 5.6, поставляемая в комплекте IB 5.6 MediaK.it Rus. — Прим. науч. ред.

(обратно)

175

Полный комплект документации по InterBase 6.x, включая ReleaseNotes по всем версиям InterBase и Firebird, можно найти нa www.ibase.ru. -Прим. науч. ред.

(обратно)

176

На русском языке- «SQL», М. Грабер, издательство «Лори», дата выхода: 2001/2003, ISBN 5-85582-109-9. — Прим. науч. ред.

(обратно)

177

И для InterBase. — Прим. перев.

(обратно)

178

Не упомянут термин Oldest Snapshot Transaction (OST) — номер транзакции, которая была старейшей активной при старте самой старой активной на текущий момент транзакции SNAPSHOT. Именно этот номер препятствует сборке мусора. Расстояние между OIT и OST используется в Firebird 1.0 и 1.5 для определения момента старта автоматической чистки мусора (sweep). — Прим. науч. ред.

(обратно)

179

Это не так. Существует много систем, в которых номер OIT отстает от Next на несколько миллионов, при этом база данных работает нормально. «Застревание» OIT является индикацией того, что где-то в базе данных есть версии записей, отмененные по rollback, которые должны быть убраны как мусор принудительным запуском sweep. — Прим. науч. ред.

(обратно)

180

Сервер оценивает селективность как число, обратное разнице общего числа ключей и числа повторяющихся значений ключей индекса (от 0 до 1). Поэтому чем меньше значение селективности (столбец rdb$indices.rdb$statistics), тем лучше. Под «низкой» селективностью здесь имеется в виду селективность, стремящаяся к 1. Под «высокой» — стремящаяся к 0. — Прим. науч. ред.

(обратно)

181

Тем не менее большинство американских программистов говорят «сиквел». — Прим. перев.

(обратно)

182

Согласно Оксфордскому словарю английского языка аббревиатура SQL расшифровывается именно как Structured Query Language — структурированный язык запросов в отношении к базам данных. Прим. науч. ред.

(обратно)

183

Совершенно не относится к InterBase и Firebird, так как индексы в них построены на базе структур b-tree, a b-tree это не «binary tree». В то время как слова Хелен правильны в отношении binary tree, структуры b-tree по определению не могут быть «разбалансированы», т. к. количество узлов от корня до листа одинаково для всех ключей индекса и равно глубине индекса. Поэтому рекомендации по поводу «разбалансированности» индексов можно игнорировать. — Прим. науч. ред.

(обратно)

скачать книгу бесплатно

Автор:

Борри Хелен

Название:

Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Жанр:

Программирование

Издательский дом:

БХВ-Петербург

Год издания:

2006

Аннотация:

Рассмотрены вопросы, необходимые разработчику для создания клиент-серверных приложений с использованием СУБД Firebird, явившейся развитием СУБД Borland Interbase 6. Содержится обзор концепций и моделей архитектуры клиент/сервер, а также практические рекомендации по работе с клиентскими библиотеками Firebird. Детально описаны особенности типов данных SQL, язык манипулирования данными (Data Manipulation Language, DML), а также синтаксис и операторы языка определения данных ( Data Definition Language, DDL). Большое внимание уделено описанию транзакций и приведены советы по их использованию при разработке приложений. Описано программирование на стороне клиента и сервера написание триггеров и хранимых процедур, создание и использование событий базы данных, обработка ошибок в коде на сервере и многое другое. Материал сопровождается многочисленными примерами, советами и практическими рекомендациями.Для разработчиков баз данных

Читать книгу On-line

Источник

О книге «Firebird. Руководство разработчика баз данных»

Произведение относится к жанру Руководства. На нашем сайте можно скачать бесплатно книгу «Firebird. Руководство разработчика баз данных» в формате fb2, epub или читать онлайн. Здесь так же можно перед прочтением обратиться к отзывам читателей, уже знакомых с книгой, и узнать их мнение. В интернет-магазине нашего партнера вы можете купить и прочитать книгу в бумажном варианте.

Источник

Хелен Борри (перевод: Александр Григорьевич Бондарь)

Базы данных Литература ХXI века (эпоха Глобализации экономики) Программирование: прочее Современные российские издания

Firebird. Руководство разработчика баз данных (fb2)

Добавлена: 18.04.2013 Версия: 1.004.
Дата создания файла: 2013-02-18
ISBN: 5-94157-609-9 Кодировка файла: windows-1251
Издательство: БХВ-Петербург
Город: Санкт-Петербург

   (Fb2-info)    (ссылка для форума)
(ссылка для блога)
(QR-код книги)

Аннотация

Рассмотрены вопросы, необходимые разработчику для создания клиент-серверных приложений с использованием СУБД Firebird, явившейся развитием СУБД Borland Interbase 6. Содержится обзор концепций и моделей архитектуры клиент/сервер, а также практические рекомендации по работе с клиентскими библиотеками Firebird. Детально описаны особенности типов данных SQL, язык манипулирования данными (Data Manipulation Language, DML), а также синтаксис и операторы языка определения данных ( Data Definition Language, DDL). Большое внимание уделено описанию транзакций и приведены советы по их использованию при разработке приложений. Описано программирование на стороне клиента и сервера написание триггеров и хранимых процедур, создание и использование событий базы данных, обработка ошибок в коде на сервере и многое другое. Материал сопровождается многочисленными примерами, советами и практическими рекомендациями.
Для разработчиков баз данных