4. Распределенные БД. Технологии файл-сервер и клиент-сервер.

   1. Распределенные бд. Технология клиент-сервер.

Файл сервер

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

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

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

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

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

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

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

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

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

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

Таблица 10.4

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

5. Распределенные базы данных. Технология тиражирования.

Тиражирование данных - это асинхронный перенос изменений объектов исходной базы данных (source database) в БД, принадлежащим различным узлам распределенной системы. Функции тиражирования данных выполняет специальный модуль СУБД - сервер тиражирования данных, называемый репликатором (replicator). Его задача - поддержка идентичности данных в принимающих базах данных (target database) данным в исходной БД. Сигналом для запуска репликатора служит срабатывание правила (см. Раздел 2), перехватывающего любые изменения тиражируемого объекта БД. Возможно и программное управление репликатором посредством сигнализаторов о событиях в базе данных.

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

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

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

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

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

6. Проблемы, возникающие при параллельном доступе, и пути их решения.

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

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

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

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