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

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

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

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

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

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

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

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

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

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

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

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

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

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

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