Понятие и архитектура распределенной субд. Стратегии распределения данных в рабд.

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

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

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

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

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

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

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

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

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

Любая распределенная СУБД должна обладать следующими характеристиками:

• иметь набор логически связанных разделяемых данных;
• сохраняемые данные должны быть разбиты на некоторое количество фрагментов;
• между фрагментами может быть организована репликация данных;
• фрагменты и их реплики распределены по различным узлам;
• узлы связаны между собой сетевыми соединениями;
• работа с данными на каждом узле управляется локальной СУБД;
• СУБД на каждом узле способна поддерживать автономную работу локальных приложений.

Двенадцать правил К. Дейта

Идея распределенной базы данных была сформулирована Кристом Дейтом в 1987 году в виде двенадцати правил. Основой этих правил является то, что распределенная база данных должна восприниматься пользователем точно так же, как и привычная централизованная база.

1. Локальная автономность. В данном контексте автономность означает следующее:

o локальные данные принадлежат локальным владельцам и сопровождаются локально;

o все локальные процессы остаются чисто локальными;

o все процессы на заданном узле контролируются только этим узлом.

2. Отсутствие опоры на центральный узел. В системе не должно быть ни одного узла, без которого система не сможет функционировать, т.е. никакой конкретный сервис (управление транзакциями, оптимизация запросов и др.) не должен возлагаться на какой-либо специально выделенный центральный узел.

3. Непрерывное функционирование. В идеале в системе не должна возникать потребность в плановом останове ее функционирования.

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

5. Независимость от фрагментации. Пользователь должен получать доступ к данным независимо от способа их фрагментации.

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

7. Обработка распределенных запросов. Система должна поддерживать обработку запросов, ссылающиеся на данные, расположенные более чем на одном узле.

8. Обработка распределенных транзакций. Система должна поддерживать выполнение транзакций.

9. Независимость от типа оборудования. Система должна быть способна функционировать на оборудовании с различными вычислительными платформами.

10. Независимость от сетевой архитектуры. Система должна быть способна функционировать в сетях с различной архитектурой.

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

12. Независимость от типа СУБД.

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