Выше, рассматривая распределенную базу данных, состоящую из локальных сайтов, мы неявно предполагали, что для каждой единицы данных существует вполне определенный единственный сайт, владеющий этими данными. Т.е. что каждый источник данных приписан одному сайту.
Однако, реальная ситуация не всегда соответствует этой схеме. Существуют мобильные пользователи (и источники данных), перемещающиеся от сайта к сайту. Отдельные данные могут передаваться с сайта на сайт в соответствии с некоторыми бизнес-процессами. При этом происходит не копирование, а именно передача, без сохранения данных на старом сайте.
В литературе рассматриваются несколько схем владения данными:
1) ведущий/ведомый;
2) рабочий поток;
3) симметричная репликация.
Схема «ведущий/ведомый» фактически уже была описана. Она заключается в том, что у любых данных имеется единственный владелец (ведущий), остальные пользователи этих данных (ведомые) производят изменения в своих копиях, может быть, асинхронно после изменения данных ведущим. Причем задержка в изменениях для разных пользователей может быть различной и даже, в крайнем случае, не производиться. Пример такого рода связан с использованием информации из Интернета. Полученная копия какого-либо документа с некоторого сайта используется в текущей работе, и в дальнейшем оказывается не нужна пользователю, даже если на сайте этот документ изменился.
Схема «рабочий поток» ориентирована на базы данных, обслуживающие бизнес-процессы. Бизнес-процесс может исполняться несколькими работниками организации, располагающими на различных сайтах. Комплект данных, сопровождающий бизнес-процесс, претерпевает изменения во время выполнения технологических операций процесса. Кроме этого, комплект данных передается с сайта на сайт, где и выполняются эти технологические операции. Логично признать, что при этом перемещении меняются и владельцы комплекта данных.
В схеме «рабочий поток» у любых данных, также как и в схеме «ведущий/ведомый», имеется единственный владелец. Однако в схеме «ведущий/ведомый» – это постоянное владение, а в схеме «рабочий поток» – временное владение, со сменой владельца. Но там и там в любой момент времени только один сайт имеет право менять конкретные данные, остальные могут только читать эти данные.
В схеме «симметричной репликации» все сайты, использующие копии БД, равноправны, т.е. все являются, одновременно, и владельцами и пользователями. Такая схема наиболее динамична и удобна для работников организации, выполняющих действия с одними и теми же записями в распределенной базе данных. При этом работники выступают и в качестве пользователей данных (чтение) и в качестве источников данных (запись, изменения). Каждый может изменять данные, но и каждый несет ответственность за достоверность изменений.
С точки зрения реализации схема «симметричной репликации» наиболее сложна. Она требует механизма выявления и разрешения конфликтов. Конфликты возникают при асинхронной репликации, если между двумя соседними моментами времени ti и ti+1 синхронизации копий БД пользователи, по крайней мере, на двух сайтах произвели изменения одних и тех же данных. Если, конечно, они произвели одинаковые изменения и знают об этом, то проблем нет. Но чаще изменения неодинаковы и/или без взаимного информирования (по какому-либо каналу передачи данных, не входящему в систему).
Примеры конфликтов.
1. На двух сайтах внесли различные записи под одним и тем же номером в структуру данных FIFO – очередь («лист ожидания»). Кто «стоит в очереди» раньше?
2. В некоторое поле, предназначенное для накопления суммы, и имевшее после синхронизации значение s на двух сайтах добавили слагаемые s1 и s2 , соответственно. Как провести обновление данных при очередной синхронизации копий? А если преобразование было более сложным, чем суммирование?
3. На двух сайтах удалили различные записи. При очередной синхронизации нужно принимать во внимание оба удаления или только одно? Если одно, то которое?
Применяются следующие механизмы разрешения:
1. Установление для каждого сайта приоритета. При конфликте принимаются во внимание изменения, произведенные сайтом с наиболее высоким приоритетом.
2. Пересчет изменений в базах. В приведенном выше примере на сайтах появились значения (s + s1) и (s + s2). При очередной синхронизации можно вычислить новое значение поля как сумму старого значения и всех приращений в копиях: s + ((s + s1) – s) + ((s + s2) – s).
3. Экстремальное значение. Подобно предыдущему механизму, но для случая, когда в определенном поле фиксируется экстремальное (минимальное или максимальное) значение. В этом случае из всех копий при синхронизации выбирается копия с экстремальным значением и принимается за новое состояние базы данных (или фрагмента).
4. Самое позднее изменение копии. Изменения на разных сайтах производились в разное время, следовательно, имеют различную актуальность. Естественно выбрать наиболее актуальную копию для последующей работы.
Разумеется, это только некоторые возможные механизмы. В зависимости от вида изменений на сайтах следует использовать другие механизмы, вплоть до неавтоматизированного (ручного) сравнения изменений в копиях и принятия решения по корректировке копий при синхронизации. Последний вариант может использоваться при относительно редкой синхронизации, например, раз в сутки.