2. Сервер InterBase

Все серверы имеют похожие принципы организации данных и управления ими. В качестве примера рассмотрим работу с сервером InterBase 6.x, который явля­ется "родным" для Delphi. Совместно с Delphi поставляются две части сервера InterBase 6.x: серверная и клиентская. Не смотря на то, что сервер InterBase по­ставляется совместно с Delphi, устанавливается он отдельно: после установки Delphi выдается запрос на установку сервера InterBase. Установка происходит в автоматическом режиме, основные файлы сервера копируются в подкаталог INTERBASE, находящийся в каталоге BORLAND. Отметим, что бесплатная пробная (trial) версия сервера доступна по адресу www.borland.com/interbase.

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

• скопировать БД на сервер;

• установить для приложения новые параметры соединения с удаленной БД.

Скопировать БД можно с помощью программ типа Проводник Windows. Клиентская часть нужна для обеспечения доступа приложения к удаленной БД.

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

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

При рассмотрении операторов языка будем опускать несущественные операнды и элементы. При описании формата операторов языка SQL используются сле­дующие правила:

• символы <и> обозначают отдельные элементы формата операторов, напри­мер, имена таблиц и столбцов, и при записи операторов SQL не указываются;

• в квадратные скобки заключаются необязательные элементы конструкций языка;

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

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

2.1. Бизнес-правила

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

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

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

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