Software & Systems

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

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

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

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

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

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

Разработка такого подхода связана с рядом сложностей:

-    использование в клиентских программах обозначений таблиц и полей (пользовательских названий), отличных от их имен в БД;

-    отсутствие у пользователей достаточных знаний о структуре БД и особенностях хранения в ней данных;

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

-    формирование сообщений об ошибках сервером БД без учета ее логической структуры;

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

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

Универсальные сообщения об ошибках БД

Сообщения об ошибке от сервера БД обычно содержат тип ошибки (в виде ее кода) и название объекта БД, явившегося причиной ее возникновения. Такими объектами, как правило, являются различные ограничения БД: уникальные и внешние ключи, уникальные индексы, ограничения not null и др. На основе информации об ошибке и о структуре БД из системного каталога БД могут быть сформированы информативные сообщения об ошибке.

В клиентских программах, работающих с БД, обозначения таблиц и полей обычно отличаются от их имен в БД. Например, таблица БД может иметь имя Goods, а в клиентском приложении данные этой таблицы могут отображаться в справочнике «Товары» или «Продукция». В формируемом сообщении об ошибке для большей его информативности необходимо указывать именно пользовательские названия таблиц и полей. Информация о пользовательских названиях таблиц и их полей может задаваться разработчиком БД и храниться в БД в отдельной таблице или как значение одного из дополнительных свойств объекта БД, например, COMMENT – для серверов Firebird и Oracle Database, Extended property – для Microsoft SQL Server.

Поля, обязательные для заполнения (ограничение not null)

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

Ограничения уникальности

Необходимость ввода уникального значения поля может требоваться в основном в трех случаях: 1) поле входит в главный ключ, 2) поле включено в уникальный ключ, 3) поле входит в уникальный индекс.

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

Ограничения внешних ключей и логические связи между таблицами

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

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

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

3.     Ситуация, аналогичная предыдущей, но только для операции изменения данных в главной таблице с ограничением no action. В этом случае сервер БД генерирует те же ошибки, что и при удалении данных.

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

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

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

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

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

Специальные сообщения об ошибках

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

Можно выделить две группы специальных сообщений об ошибках БД:

-     сообщения уровня БД, предназначенные для использования во всех приложениях, работающих с общей БД;

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

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

Комплексное использование сообщений об ошибках

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

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

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

Описываемый метод формирования информативных сообщений об ошибках БД может быть применим для большинства реляционных СУБД. Примеры использования данного метода для СУБД Firebird, Microsoft SQL Server и Oracle Database рассмотрены в публикациях [1–3]. Реализация данного метода позволит уменьшить трудозатраты при разработке ПО, повысить его надежность и качество.

Литература

1.     Лихачев В.Н. Сообщения об ошибках ограничений внешних ключей на примере БД Firebird // RSDN Magazine. 2009. № 2.

2.     Лихачев В.Н. Обработка ошибок и формирование сообщений об ошибках для баз данных Microsoft SQL Server 2005/2008. URL: http://itband.ru/2010/09/sql-error/ (дата обращения: 21.09.2010).

3.     Лихачев В.Н. Особенности обработки ошибок сервера базы данных Oracle // Oracle Magazine Rus: электрон. журнал. 2009. № 6. URL: http://www.oracle.com/global/ru/oramag/ju­ly2009/russia_serv_errora.html (дата обращения: 20.11.2010).