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

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

Бизнес-правила — это процедуры управления, которые определяют, как клиент должен получать доступ к данным на сервере. Эти правила реализуются программным текстом клиента, сервера или ими обоими. Например, в Delphi бизнес-правила реализуются в программах на языке Object Pascal. На стороне сервера бизнес-правила реализуются в виде хранимых процедур SQL, триггеров и других объектов, присущих серверным базам данных. В трехуровневой модели бизнес-правила могут быть реализованы на среднем уровне. Важно понимать, что бизнес-правила определяют поведение всей системы. При их отсутствии у вас есть просто данные на одном компьютере и приложение с графическим интерфейсом на другом, однако нет метода их соединения.

На определенном этапе разработки вашей системы необходимо решить, какие процессы должны будут в ней существовать. Например, рассмотрим систему складского учета. Ей свойственны следующие типичные процессы: прием заказа, печать накладной, добавление заказчика и т.п. Как указывалось выше, все правила выполнения этих операций реализуются в коде Object Pascal на стороне клиента или на среднем уровне. Эти бизнес-правила также могут располагаться в виде SQL-кода на сервере или представлять собой комбинацию всех трех вариантов. Если большая часть правил реализована на сервере, то его называют "толстым сервером". Если правила реализуются в основном на стороне клиента, он называется "толстым клиентом". Если правила реализованы на среднем уровне, то сервер также называют "толстым". То, на какой именно стороне реализуются бизнес-правила приложения, определяется объемом и типом требуемых операций управления данными.

В литературе наряду с термином трехуровневая система иногда встречаютсятермины n -уровневая или многоуровневая (multitier) система, которые порой употребляются некорректно. В трехуровневой модели обычно существует один или более клиентов, бизнес-логика и сервер базы данных. Поддержка бизнес-логики может быть разделена на несколько частей, выполняемых на различных компьютерах или даже на нескольких серверах приложений. Не кажется ли вам абсурдом упоминание 10-, 15- или даже 25-уровневых систем? Мы предпочита­ем рассматривать всю поддержку бизнес-логики как один средний уровень, не­зависимо от количества подпрограмм и серверных приложений, потребовавших­ся для ее реализации.

Вероятно, вы часто слышали о системах клиент/сервер, относящихся к одной из двух моде­лей. Это двухуровневая и трехуровневая модели, показанные на рис. 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 Гбайт
Максимальное число таблиц в одной БД
Максимальное число полей (столбцов) в одной таблице
Максимальное число записей в одной таблице	Не ограничено
Максимальная длина записи	64 К (не считая полей BLOB)
Максимальная длина поля	32 К (кроме полей BLOB)
Максимальная длина поля BLOB	Не ограничена
Максимальное число индексов в БД
Максимальное число полей в индексе
Максимальное число вложенностей SQL-запроса
Максимальный размер хранимой процедуры или триггера	48 К
Максимальное количество UDF в базе данных	Длина имени UDF - не более 31 сим­волов. Каждый UDF должен иметь уникальное имя. Максимальное число UDF ограничивается только требованием уникальности имени

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

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

2.5.2. Основные компоненты.

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

Для задания ссылочной и смысловой целостности в БД определяются:

· отношения подчиненности между таблицами БД путем определения первичных (PRIMARY) ключей у родительских и внешних (FOREIGN) ключей у дочерних таблиц;

· ограничения на значения отдельных столбцов путем определения ограничений (CONSTRAINT) на значение домена или столбца; при этом условия ограничений могут быть весьма разнообразны - от требования попадания значения в определенный диапазон или соответствия маске до определенного отношения с одной или несколькими записями из другой таблицы (или многих таблиц) БД;

· бизнес-правила при помощи триггеров (TRIGGER) - подпрограмм, автоматически выполняемых сервером до или (и) после события изменения записи в таблице БД;

· уникальные значения нужных полей путем создания и использования генераторов (GENERATOR).

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

· отпадает необходимость синтаксической проверки каждого запроса и его компиляции перед выполнением, что убыстряет выполнение запросов; отпадает необходимость реализации в приложении запросов, определенных в теле хранимых процедур;

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

В составе записи БД могут определяться BLOB-поля (Binary Large Object, большой двоичный объект), предназначенные для хранения больших объемов данных в виде последовательности байтов. Таким образом могут храниться текстовые и графические документы, файлы мультимедиа, звуковые файлы и т.д. Интерпретация BLOB-поля выполняется в приложении, однако разработчик может определить так называемые BLOB-фильтры для автоматического преобразования содержимого BLOB-поля к другому виду.

InterBase дает возможность использовать определяемые пользователем функции (User Defined Function, UDF), в которых могут реализовываться функциональности, отсутствующие в стандартных встроенных функциях InterBase (вычисление максимума, минимума, среднего значения, преобразование типов и приведение букв к заглавным). Например, в UDF можно реализовать извлечение из значения даты номера дня, года; определение длины символьного значения; усечение пробелов; разные математические алгоритмы и другое. Функция пишется на любом алгоритмическом языке, позволяющем разрабатывать DLL (библиотеки динамического вызова), например на Object Pascal.

InterBase может посылать уведомления клиентским приложениям о наступлении какого-либо события (EVENT). Одновременно работающие приложения могут обмениваться сообщениями через сервер БД, вызывая хранимые процедуры, в которых реализована инициация нужного события.

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

Для доступа к БД используется утилита Windows Interactive SQL (WISQL). Она работает с БД напрямую через InterBase API, минуя BDE. В WISQL можно выдавать любые запросы, будь то создание БД, таблиц, изменение структуры данных, извлечение данных из БД или их изменение, а также назначение прав доступа к информации для отдельных пользователей.

Для управления SQL-сервером в целом и отдельными БД в частности используется утилита InterBase Server Manager. Здесь можно определять параметры SQL-сервера, производить сохранение, восстановление БД, сборку "мусора", определять новых пользователей, их пароли и т.д.

Для просмотра БД, работы с таблицами, индексами, доменами, ограничениями и др. могут использоваться утилиты Database Desktop (весьма ограниченно) и SQL Explorer.

Для просмотра и анализа реальных процессов, происходящих на сервере при реализации пользовательского запроса, используется утилита SQL Monitor.

2.5.3. Физическая организация базы данных.

База данных InterBase состоит из последовательно, начиная с 0, пронумерованных страниц. Нулевая страница является служебной и содержит информацию, необходимую для соединения с БД.

Размер страницы - 1 (по умолчанию), 2, 4 или 8 Кбайт. Размер страницы устанавливается при создании БД, но может быть изменен при сохранении и восстановлении БД. Одна страница читается сервером за один логический доступ к БД. Поэтому размер страницы рекомендуется делать равным размеру кластера диска, однако в зависимости от того, какие операции чаще выполняются для БД - операции чтения или записи, - рекомендуется соответствующим образом изменять размер страницы, учитывая также длину записи и наличие BLOB.

Объем буфера ввода-вывода для операций чтения-записи определяется в количестве страниц (по умолчанию - 75). Если БД будет чаще читаться, объем буфера следует увеличить. Если в нее будет чаще осуществляться запись, размер буфера следует уменьшить.

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

InterBase располагает на одной странице БД версии одной записи таблицы БД. После удаления записей на странице образуются "дырки". При добавлении новой записи анализируется размер максимальной дырки и, если он меньше длины добавляемой записи, происходит компрессия страницы, в процессе которой "дырки" объединяются. Если суммарной "дырки" не хватает для размещения новой записи, та записывается с новой страницы. Загрузка страницы считается нормальной в случае, если "дырки" занимают не более 20% объема страницы.

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

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

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

Существует несколько способов проведения дефрагментации.

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

Второй способ состоит в автоматическом сборе мусора. Интервал (sweep interval), через который происходит сборка мусора, измеряется в транзакциях. По умолчанию автоматический сбор мусора производится через каждые 20 000 транзакций. Этот показатель может быть изменен в утилите InterBase Server Manager. Там же может быть предпринята принудительная сборка мусора. Данный способ дефрагментации БД менее предпочтителен, поскольку удаляются только те старые версии записей, для которых нет активных транзакций. В результате могут быть удалены не все старые версии. При большом числе активных транзакций процесс сборки мусора может существенно замедлить их выполнение.

Дата добавления: 2014-01-05