2.4.4. Модели архитектуры клиент-сервер.

Вероятно, вы часто слышали о системах клиент/сервер, относящихся к одной из двух моде­лей. Это двухуровневая и трехуровневая модели, показанные на рис. 2.1 и 2.2 соответственно.

На рис. 2.1 представлена схема двухуровневой модели клиент/сервер. Эта модель, воз­можно, наиболее общая, поскольку она следует схеме построения локальных баз данных. Многие из уже существующих ныне систем клиент/сервер развивались из приложений, ис­пользовавших локальные базы данных, размещенных в сетях персональных компьютеров на совместно используемых файловых серверах. Перенос на SQL-серверы систем, основанных на совместно используемых файлах Paradox или dBASE,. осуществлялся с целью повышения эффективности их работы, защищенности и надежности базы данных.

В такой модели данные постоянно находятся на сервере, а клиентские приложения — на компьютере пользователя. Бизнес-правила при этом могут располагаться на любом из ком­пьютеров (или даже на обоих одновременно).

Рис. 2.1. Двухуровневая модель клиент-сервер.

Рис. 2.2. Трехуровневая модель клиент-сервер.

На рис. 2.2 показана трехуровневая модель клиент/сервер. Здесь клиент — это пользова­тельский интерфейс доступа к данным. Данные находятся на удаленном сервере. Клиентское приложение делает запросы для получения доступа или изменения данных через сервер при­ложений или сервер Remote Data Broker (Удаленный брокер-сервер данных) — RDB. Обычно бизнес-правила располагаются именно на сервере RDB.

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

2.5. Знакомство с субд Borland InterBase.

Для реализации архитектуры клиент-сервер применяют так называемые "промышленные" ("удаленные") СУБД, такие как Borland InterBase, Oracle, Informix, Sybase, DB2, MS SQL Server.

SQL-сервер Borland InterBase является "промышленной" СУБД, предназначенной для хранения и выдачи больших объемов данных при использовании архитектуры "клиент-сервер" в условиях одновременной работы с БД множества клиентских приложений. Масштаб информационной системы при этом произволен - от системы уровня рабочей группы (под управлением Novell Netware или Windows NT, 2000, XP на базе IBM PC) до системы уровня большого предприятия (на базе серверов IBM, Hewlett-Packard, SUN).

2.5.1. История создания и некоторые технические характеристики.

InterBase был разработан в начале 80-х годов группой разработчиков из американской корпорации DEC. В дальнейшем разработка данного продукта велась независимыми компаниями InterBase Soft­ware и впоследствии слившейся с ней Ashton-Tate. Borland приобрела права на InterBase у Ashton-Tate после слияния с нею.

InterBase активно используется в США в государственном и военном секторах, что, видимо, и стало преградой для движения InterBase в страны СНГ. В СНГ InterBase используется с 1993 г. Внимание разработчиков БД и приложений InterBase привлек, во-первых, потому, что InterBase весьма прост в установке, настройке и - главное - в администрировании по сравнению с другими SQL-серверами, и во-вторых, потому, что он обладает прекрасными функциональными возможностями.

Таблица 2.1.

Некоторые технические характеристики сервера InterBase.

Характеристика	Значение
Максимальный размер одной БД	Рекомендуется не выше 10 Гбайт. Однако известны случаи объема одной БД в 10-20 Гбайт
Максимальное число таблиц в одной БД	65536
Максимальное число полей (столбцов) в одной таблице	1000
Максимальное число записей в одной таблице	Не ограничено
Максимальная длина записи	64 К (не считая полей BLOB)
Максимальная длина поля	32 К (кроме полей BLOB)
Максимальная длина поля BLOB	Не ограничена
Максимальное число индексов в БД	65536
Максимальное число полей в индексе	16
Максимальное число вложенностей SQL-запроса	16
Максимальный размер хранимой процедуры или триггера	48 К
Максимальное количество UDF в базе данных	Длина имени UDF - не более 31 сим­волов. Каждый UDF должен иметь уникальное имя. Максимальное число UDF ограничивается только требованием уникальности имени

Локальный InterBase может использоваться для отладочных целей. После того, как приложение отлажено на локальной версии SQL-сервера, происходит масштабирование приложения (upsizing). БД переносится на сетевой сервер, а изменения в клиентских приложениях при этом минимальны - необходимо изменить псевдоним БД и, может быть, скорректировать некоторые параметры соединения приложения с сервером.

При переносе приложений, ранее разработанных для применения в архитектуре "файл-сервер", требуется не только частично или полностью переписывать приложения клиентов, но и преобразовывать локальную БД в серверную. Для этого под управлением серверной СУБД (например, InterBase) создают БД на сервере, куда затем "перекачивают" данные из локальных СУБД, реализованных, например, с помощью Paradox или FoxPro. Основная проблема, встающая в этом случае - несовместимость некоторых форматов данных или их отсутствие. Например, InterBase не поддерживает поля типа Boolean (Logical), и их необходимо реализовывать при помощи столбцов типа CHAR(l); InterBase не поддерживает автоинкрементные поля Paradox - для обеспечения уникальности значений в числовых полях в БД InterBase используют генераторы и т.д. При возникновении подобных проблем следует изучить вопросы совместимости типов данных локальной СУБД и выбранной серверной СУБД.