Способы реализации распространения изменений

Модели владения данных

	статическое		динамическое

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

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

"модель динамического владения, основанная на последовательности выполняемых действий (workflow)" и "модель динамического владения с передачей маркера (token Passing)" применяемые в Oracle.

10.М одель динамического владения, основанная на последовательности выполняемых действий (workflow)

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

Модель динамического владения с передачей маркера (token Passing)"

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

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

Возможности предотвращения конфликтов уникальности и конфликтов удаления.

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

- поделить множество значений межу узлами непересекающимся образом.

- использование глобально уникальных значений (в Oracle его можно получить с помощью функции SYS_GUID).

1. использовании триггеров.

Триггеры – это процедуры, которые срабатывают при наступлении определенных событий (например, insert, delete, update). Внутрь триггера помещаются команды, проводящие на других копиях обновления, аналогичные тем, которые вызвали выполнение триггера.

Недостатки:

– триггеры создают дополнительную нагрузку на систему;

– триггеры не могут выполняться по графику (время срабатывания триггера не определено);

– с помощью триггеров сложнее организовать групповое обновление связанных таблиц (из-за проблемы мутирующих таблиц).

2. поддержка журналов изменений для реплицируемых данных. Рассылка этих изменений входит в задачу сервера СУБД или сервера тиражирования (входящего в состав СУБД).

Основные принципы, которых необходимо придерживаться при этом:

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

2. Информация об изменениях должна сохраняться в журнале до тех пор, пока не будут обновлены все копии этих данных.

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