Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 61)

В системах с «клиент-серверной» архитектурой (рис. 10.3) основ­ная обработка данных проводится на сервере.

«Клиент-серверные» системы имеют следующие преимущества:

• снижение сетевого трафика за счет выполнения запросов на сервере;

• оптимизация выполнения запросов;

• возможность хранения бизнес-правил на сервере (ограничения целостности, хранимые процедуры, отражающие логику обработки);

• возможность использования CASE-средств для генерации кодов серверных объектов (триггеров, хранимых процедур, текстов SQL-запросов);

• управление пользовательскими привилегиями и правами доступа;

• широкие возможности резервного копирования и архивации данных.

Сравнительные характеристики технологий «файл-сервер» и «кли­ент-сервер» приведены в табл. 10.4.

Таблица 10.4

Характеристика	«Файл-сервер»	«Клиент-сервер»
Интенсивность сетевого трафика		+
Обеспечение целостности данных		+
Обеспечение безопасности данных		+
Устойчивость к сбоям		+
Сложность проектирования	+
Сложность эксплуатации системы	+
Ограничения на число пользователей		+

При обработке данных в сетевой среде выделяют следующие ос­новные группы выполняемых функций:

• презентационная логика (Presentation Layer - PL);

• бизнес-логика (Business Layer - BL);

• логика доступа к ресурсам (Access Layer - AL).

По характеру распределения функций между клиентом и серве­ром различают системы с тонким клиентом, толстым клиентом и системы с трехслойной (трехуровневой) архитектурой.

Модель с тонким клиентом стала активно использоваться в кор­поративной среде в связи с распространением интернет-технологий, и в первую очередь Web-браузеров. В этом случае клиентское прило­жение обеспечивает реализацию PL, а сервер объединяет BL и AL.

Модель с толстым клиентом наиболее часто встречается в уже внедренных и активно используемых системах. Такая модель подра­зумевает объединение в клиентском приложении как PL, так и BL. Серверная часть при описанном подходе представляет собой сервер баз данных, реализующий AL. К описанной модели часто применяют аббревиатуру RDA - Remote Data Access.

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

Как видно из вышеизложенного, существует множество разнооб­разных технологий работы в распределенной среде.

Некоторые из них представляют собой реализацию на новом технологическом уровне ранее использовавшихся подходов к организа­ции обработки информации.

РБнД могут быть реализованы на однородных элементах (гомо­генные системы) или на разнородных (гетерогенные системы). По­скольку процесс создания информационной системы практически непрерывен, то обычно эти системы являются гетерогенными. Разно­родными могут быть ЭВМ, ОС, СУБД.

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

• собственные сетевые драйверы (native software drivers);

• шлюзы (gateways);

• промежуточное программное обеспечение (middleware).

10.3. Транзакции

10.3.1. Понятие транзакции

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

Понятие транзакция широко используется в АИС и может отно­ситься не только к распределенным банкам данных. Однако в РБнД оно становится особенно значимым.

К транзакциям предъявляется набор требований, известный под названием ACID (Atomicity, Consistency, Isolation, Durability). Эти тре­бования вытекают из определения транзакции.

Атомарность (atomicity). Транзакция представляет собой некото­рый набор законченных действий. Система обеспечивает их выполне­ние по принципу «все или ничего» - либо выполняются все действия, тогда транзакция «фиксируется»; либо, если возможность выполнить все действия отсутствует, например в случае сбоев, транзакция «отка­тывается» назад, а БД остается в исходном состоянии.

Согласованность (consistency). Предполагается, что в результате выполнения транзакции система переходит из одного корректного состояния в другое.

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

Долговечность (durability). Если транзакция зафиксирована, то ее результаты должны быть долговечными. Новые состояния всех объек­тов сохранятся даже в случае аппаратных или системных сбоев.

Конкретные СУБД используют различные механизмы управления транзакциями. Некоторые СУБД для задания транзакции используют операторы BEGIN TRANSACTION-END TRANSACTION, и все ко­манды, заключенные между ними, составляют транзакцию. В неко­торых системах считается, что, инициируя сеанс работы с SQL, пользо­ватель начинает транзакцию, которая будет продолжаться, пока не будет введен оператор COMMIT WORK, который сделает все изме­нения, проведенные в ходе транзакции, постоянными, или оператор ROLLBACK WORK, который отменяет все сделанные в транзакции изменения. После каждого оператора COMMIT или ROLLBACK на­чинается новая транзакция.

Во многих СУБД присутствует специальный параметр AUTO-COMMIT, который, находясь во включенном состоянии, приводит к автоматической фиксации изменений каждой нормально завершен­ной операции.

Транзакция может быть помечена как «только чтение» (READ ONLY). При выполнении такой транзакции попытка провести изме­нение данных будет вызывать сообщение об ошибке. Задание при­знака READ ONLY позволяет увеличить производительность как этой, так и параллельно исполняемых транзакций.

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

10.3.2. Плоские транзакции

Модели плоских транзакций соответствует один управляющий слой, которому подчинено произвольное число элементарных дей­ствий.

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

10.3.3. Контрольные точки

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

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

По достижении очередной контрольной точки в транзакции со­здается новое атомарное действие, которое запускается на выполне­ние. Только последнее атомарное действие всей последовательности может выполнить фиксацию (COMMIT WORK) транзакции; опера­тор COMMIT WORK передается всем предыдущим атомарным дей­ствиям, пока все они не будут зафиксированы. Контрольная точка не приводит к необратимой фиксации выполненной до этого момента работы.

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

10.3.4. Многозвенные транзакции

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

Модель многозвенных транзакций включает оператор CHAIN WORK - неделимую комбинацию операторов BEGIN WORK и COMMIT WORK, которая неравноценна последовательному выпол­нению операторов BEGIN WORK и COMMIT WORK по отдельнос­ти. При выполнении этих операторов по отдельности контекст про­падает; некоторая другая транзакция может вклиниться и изменить значения в базе данных, которые нужны для выполнения следующего звена многозвенной транзакции, прежде чем это звено начнет выпол­няться. Таким образом, многозвенные транзакции концептуально эк­вивалентны транзакциям с контрольными точками с той разницей, что откат может проводиться только до последней зафиксированной точки, а не до любой предыдущей контрольной точки.

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

10.3.5. Вложенные транзакции

Модель вложенных транзакций включает понятие головной тран­закции, которая управляет выполнением всей иерархии. В разках иерархии могут присутствовать транзакции разных уровней вложен­ности. Концевые узлы иерархии представляют собой плоские тран­закции. Отдельные ветви иерархии могут иметь разную длину, т.е. концевые транзакции могут находиться на разном расстоянии от го­ловной транзакции (корня дерева транзакций). Вложенные транзак­ции называются также гнездующимися.

10.4. Проблемы параллелизма и пути их решения

10.4.1. Параллелизм

При параллельном выполнении операций над базой данных мо­гут возникать некоторые проблемы. Одна из них - проблема утра­ченных (потерянных) обновлений (Lost update) - заключается в том, что если пользователи параллельно обновляют одни и те же данные, то запомненным будет то обновление, которое было проведено по­следним. Остальные обновления будут потеряны (рис. 10.4).

Другая проблема - зависимость от незафиксированных обновлений - состоит в том, что пользователь А может увидеть данные, кото­рые уже были обновлены пользователем В, но эти обновления еще не были окончательно зафиксированы. Далее пользователь В может в силу [различных причин, например из-за выявленных ошибок ввода, провести откат базы данных в исходное состояние (рис. 10.5). Пользо­ватель А в этом случае будет предпринимать действия над ошибоч­ными (данными. Иногда для такого рода проблем используется тер­мин преждевременное чтение (Dirty read).

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

Характеристики

Список файлов книги