9.4. Исключения

Система уведомляет об исключительных ситуациях, или исключениях (exceptions), встреченных ею в процессе выполнения SQL-команд, присваивая переменной sqlstate соответствующие символьные представления последовательностей из пяти десятичных цифр (код '00000' означает, что ошибок нет). Один из примеров кодов ошибок: '02000' — "кортеж не найден". В качестве другого примера можно привести код '21000', свидетельствующий о том, что команда выбора единст­венного кортежа возвратила более одного кортежа.

Стандарт PSM предусматривает возможность объявления специального фрагмента кода, называемого обработчиком исключений (exception handler), который вызывается всякий раз, когда любое значение из списка заданных кодов ошибок присваивается системой переменной sqlstate в процессе выполнения команд текущего блока кода. Каждый обработчик исключений ассоциируется с определенным блоком кода вида begin. . .end (а именно с тем, которому принадлежит сам обработчик) и ограничива­ет свое "влияние" только содержимым этого блока.

Компонентами конструкции обработчика исключений служат:

1)   список условий исключений, провоцирующих вызов обработчика;

2)   фрагмент кода, подлежащего выполнению, если сгенерировано одно из ука­занных исключений;

3)   одно из служебных слов, указывающих на то, куда следует передать управ­ление по завершении выполнения кода обработчика.

Выражение определения обработчика исключения можно описать следующим образом:

DECLARE <куда идти> HANDLER FOR  <кто виноват> <что делать>

Альтернативные варианты ответа на вопрос "куда идти" таковы:

a)  continue — после выполнения выражения "что делать" перейти к очеред­ному выражению текущего блока кода begin. .. end;

b)   exit — по завершении выражения "что делать" покинуть текущий блок ко­да и передать управление выражению, следующему за блоком;

c)  undo — вариант, аналогичный exit, за "исключением" того, что все из­менения, которые затронули содержимое базы данных и локальных перемен­ных подлежат отмене.       

 

Архитектура приложения на основе СУБД.

Архитектура приложения, использующего СУБД определяется, прежде всего архитектурой используемой СУБД

Существующие архитектуры СУБД разделяется на:

• Обеспечивающие локальные БД, то есть БД, хранящиеся на одном рабочем месте и работа с БД, которая производится на данном одном рабочем месте;

• Обеспечивающие БД, построенные в виде иерархических сетей, т.е. БД централизованной архитектуры;

• Обеспечивающие построение БД, на основе архитектуры "клиент-сервер" (см. курс ИТ).

В СУБД с централизованной архитектурой, СУБД и сама база данных размещается и функционирует на центральном миникомпьютере (мэйнфрейме), а пользователи получают доступ к базе данных при помощи обычных терминалов - компьютер рассматривается просто как устройство ввода и отображения информа­ции: на мэйнфрейм передаются нажатия клавиш, в обратном направлении передаются данные, отображае­мые непосредственно на мониторе пользователя. Примерами СУБД с централизованной архитектурой являются ранние версии СУБД DB2, ранние версии СУБД Oracle и Ingres.

Разновидности архитектуры "клиент-сервер" определяют, какие компоненты приложения распределены на клиенте и на сервере, и особенности этих компонент.

В приложении выделяются следующие компоненты – представительная (отображение ввод), прикладная компонента (выполнение прикладной логики), компонента хранимых данных, вспомогательные компоненты.

Архитектура клиент-сервер разделяется на архитектуры (см курс ИТ)

• Файл-сервер,

RDA.

• «сервер БД»

• СУБД с трехуровневой архитектурой: "тонкий клиент" — сервер приложений — сервер базы данных.

Особенностью приложений, построенных на основе СУБД, является разделение прикладной компоненты на дополнительные компоненты составляющие:

• компоненту обработки логики программного кода, данная компонента реализует логику отображения данных, обработку ввода, выявление ошибок ввода;

• компоненту, реализующую бизнес логику, то есть логику работы прикладной области;

• компоненту, реализующую логику управления данными (выборка данных, связь выбираемых данных, сортировка)

Логика (отображения) обработки ввода, вывода, обычно располагается на стороне клиента. Она может быть встроена в графический интерфейс пользователя. Некоторые ее компоненты могут располагаться на сервере.

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

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

Логика управления данными обычно располагается на сервере БД, однако может вынесена на сервер приложений и некоторые элементы на сторону клиента.

Построение БД по технологии "клиент-сервер" выделяется особый стиль "сервер транзакций".

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

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

Выбор определенного стиля "клиент-сервер" зависит от особенностей бизнес-логики в рассматриваемой предметной логике.

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