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

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

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

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

При работе в архитектуре "клиент-сервер" приложение должно:

    • устанавливать соединение с сервером и завершать его;
    • формировать и отсылать запрос серверу, получая от него результаты выполнения запроса;
  • обрабатывать полученные данные.

При этом обработка данных не имеет принципиальных отличий по сравнению с обработкой данных в локальных БД.

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

    • триггеры;
    • генераторы;
    • хранимые процедуры;
    • функции, определяемые пользователем;
    • механизм транзакций;
  • механизм кэшированных изменений;

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

Система Delphi обеспечивает разработку приложений для различных серверов, предоставляя для этого соответствующие средства. Отметим, что многие описанные ранее принципы разработки приложений и средства для работы с локальными БД относятся и к работе с удаленными БД. В частности, для разработки приложений используются такие компоненты, как источник данных DataSource,_наборы данных Table, ADOTable, SQLTable, IBTable, Query, ADOQuery, SQLQuery, сетка DBGrid и др.

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

Напомним, что если при выполнении модифицирующего БД запроса с помощью компонента Query не нужен результирующий набор данных, то этот запрос предпочтительнее выполнять с помощью метода ExecSQL. Для работы с таблицами и запросами по-прежнему можно использовать такие программы, как Database Desktop и SQL Explorer.

Средства Delphi, предназначенные для работы с удаленными БД, можно разделить на два вида: инструменты и компоненты.

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

    • InterBase Server Manager - программа управления запуском сервера InterBase;
    • IBConsole - консоль сервера InterBase;
  • SQL Monitor - программа отслеживания порядка выполнения SQL-запросов к удаленным БД.

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

    • Database (соединение с БД);
    • Session (текущий сеанс работы с БД);
    • StoredProc (вызов хранимой процедуры);
    • UpdateSQL (модификация набора данных, основанного на SQL-запросе);
    • DCOMConnection (DСОМ-соединение);
  • компоненты страниц АDО, dbExpress, Interbase Палитры компонентов.

Отметим, что многие из названных компонентов, например, Database, Session, UpdateSQL, используются также при работе с локальными БД. Так, компонент Database позволяет, реализовать механизм транзакций при навигационном способе доступа к данным с помощью механизма ВDЕ. Однако наиболее часто эти компоненты применяются именно при работе с удаленными базами. Часть компонентов, например, клиентский набор данных ClientDataSet и соединение с сервером DCOMConnection, предназначена для работы в трехуровневой (трехзвенной) архитектуре "клиент-сервер" ("тонкий" клиент) и используется для построения сервера приложений.

В основе операций, выполняемых с удаленными БД как с помощью инструментов, так и программно, лежит язык SQL. Например, при создании таблицы с помощью программы IBConsole необходимо набрать и выполнить SQL-запрос (инструкцию) Create Table. Если создание таблицы с помощью механизма ВDЕ осуществляется из приложения пользователя, то для этой цели используется набор данных Query, который выполняет такой же запрос. Основное различие заключается в том, каким образом выполняется SQL-запрос к удаленной БД.

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

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

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

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

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

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

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

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

Информация всей БД сервера InterBase хранится в одном файле с расширением gdb. Размер этого файла может составлять единицы и даже десятки гигабайт. Отметим, что аналогичный размер БД имеет СУБД Microsoft SOL Server, в то время как для более мощных СУБД Oracle и SyBase размер БД достигает десятков и сотен гигабайт.

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

Элементы структуры удаленной БД также называют метаданными. Слово "мета" имеет смысл "над", т. е. метаданные представляют собой данные, которые описывают структуру БД. Для InterBase максимальное число таблиц в БД равно 65 536, а максимальное число столбцов в таблице - 1000. Отметим, что таблицы InterBase имеют меньшее число допустимых типов столбцов (полей), чем таблицы локальных БД Paradox.

Домен представляет собой именованное описание столбца. После определения домена его имя можно использовать для описания других столбцов. Аналогом домена является тип данных.

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

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

    • вместо текста запроса серверу передается по сети короткое обращение к хранимой процедуре;
  • хранимая процедура не требует предварительной синтаксической проверки.

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

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

Механизм кэшированных изменений заключается в том, что на компьютере клиента в кэше (буфере) создается локальная копия данных, и все изменения в данных выполняются в этой копии. Для хранения локальной копии используется специальный буфер (кэш). Сделанные изменения можно подтвердить, перенеся их в основную БД, хранящуюся на сервере, или отказаться от них. Этот механизм напоминает механизм транзакций, но, в отличие от него, снижает нагрузку на сеть, т. к. все изменения передаются в основную БД одним пакетом. Следует иметь к виду, что для всех записей локальной копии отсутствуют блокировки на изменение их значений. Блокировки могут быть установлены другими приложениями для основной БД, находящейся на сервере. Механизм кэшированных изменений реализуется в приложении, для чего компоненты, в первую очередь Database, Table и Query (используемые при доступе с помощью BDE), имеют соответствующие средства. Кроме того, механизм кэшированных изменений поддерживается предназначенным для этого компонентом UpdateSQL.Основные достоинства рассматриваемого механизма проявляются для удаленных БД, но его можно использовать и при работе с локальными БД.

Привилегии представляют собой права доступа к БД. Управление привилегиями заключается в их установке и удалении. После создания объекта БД (например, таблицы) доступ к ней разрешен только создателю и системному администратору, имеющему имя SYSDBA. Для доступа к БД остальных пользователей им нужно назначить соответствующие привилегии. Сразу после появления нового пользователя, созданного например, с помощью программы InterBase Manager Server , этот пользователь имеет минимальные права доступа: ему разрешено только войти в БД (соединиться с ней), указав свое имя и пароль, однако ни один объект этой БД ему не доступен. Чтобы обеспечить возможность активной работы с БД, нужно определить (переопределить) привилегии.

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