1. Фрагментация

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

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

1. Горизонтальная фрагментация. Это процесс разбиения отношения на подмножества кортежей, когда в каждом узле хранится определенное подмножество. Например, в рассмотренной нами базе данных Проекты-Поставщики-Поставки отношение Поставки может быть разбито на подмножества, соответствующие проектам, которые могут храниться в разных узлах.

2. Вертикальная фрагментация. Это процесс разбиения отношения по атрибутам.

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

2. Репликация

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

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

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

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

На практике большинство распределенных систем баз данных поддерживают определенный уровень репликации данных, что, к сожалению, также ведет к возникновению сложностей.