- •Содержание.
- •2.1. Область применения субд.
- •2.2. Ручные картотеки – файловые системы – современные субд.
- •2.3. Сравнение локальных субд с субд архитектуры клиент-сервер.
- •2.4. Архитектура клиент-сервер.
- •2.4.1. Клиент.
- •2.4.2. Сервер.
- •2.4.3. Бизнес-правила.
- •2.4.4. Модели архитектуры клиент-сервер.
- •2.5. Знакомство с субд Borland InterBase.
- •2.5.1. История создания и некоторые технические характеристики.
- •2.5.2. Основные компоненты.
- •2.5.3. Физическая организация базы данных.
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 Software и впоследствии слившейся с ней 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 используют генераторы и т.д. При возникновении подобных проблем следует изучить вопросы совместимости типов данных локальной СУБД и выбранной серверной СУБД.