Модель сервера базы данных (dbs).

Развитием RDA-модели стала модель сервера базы данных. Ее сердцевиной является механизм хра­нимых процедур. В отличие от RDA-модели, определенные для конкретной предметной области АИС события, правила и про­цедуры, описанные средствами языка SQL, хранятся вместе с данными на сервере системы и на нем же выполняются. Иначе говоря, прикладной компонент полностью размещается и вы­полняется на сервере системы.

На клиентских установках в DBS-модели размещается только интерфейсный компонент (компонент представления) АИС, что существенно снижает требования к вычислитель­ной установке клиента. Пользователь через интерфейс системы на клиентской установке направляет на сервер базы дан­ных только лишь вызовы необходимых процедур, запросов и других функций по обработке данных. Все затратные операции по доступу и обработке данных выполняются на сервере и кли­енту направляются лишь результаты обработки, а не наборы данных, как в RDA-модели. Этим обеспечивается существен­ное снижение трафика сети в DBS-модели по сравнению с RDA - моделью. Однако на сервере системы выпол­няются процедуры прикладных задач одновременно всех пользователей системы. В результате резко возрастают тре­бования к вычислительной установке сервера.

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

К числу подобных издержек относятся:

• потерянные изменения;

• «грязные» данные;

• неповторяющиеся чтения.

Потерянные изменения возникают тогда, когда две тран­закции одновременно изменяют один и тот же объект базы данных. В том случае, если в силу каких-либо причин, напри­мер, из-за нарушений целостности данных, происходит откат, скажем, второй транзакции, то вместе с этим отменяются и все изменения, внесенные в соответствующий период времени пер­вой транзакцией. В результате первая еще не завершившаяся транзакция при повторном чтении объекта не «видит» своих ранее сделанных изменений данных. Способом пре­одоления подобных ситуаций является запрет изменения дан­ных любой другой транзакцией до момента завершения пер­вой транзакции — так называемая блокировка объекта.

«Грязные» данные возникают тогда, когда одна транзак­ция изменяет какой-либо объект данных, а другая транзакция в этот момент читает данные из того же объекта. Так как первая транзакция еще не завершена, и, следовательно, не про­верена согласованность данных после проведенных, или вовсе еще только частично проведенных изменений, то вторая тран­закция может «видеть» соответственно несогласованные, т. е. «грязные» данные. Способом недопущения таких ситуаций может быть запрет чтения объекта любой другой транзакцией, пока не завершена первая транзакция, его изме­няющая.

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

С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций.

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

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

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