Гомогенные и гетерогенные распределенные БД

РаБД можно классифицировать на гомогенные и гетерогенные.

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

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

 

 

70.Распределенные СУБД (РаСУБД). Двенадцать правил К. Дейта

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

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

· набор логически связанных разделяемых данных;

· сохраняемые данные разбиты на некоторое количество фрагментов;

· между фрагментами может быть организована репликация данных;

· фрагменты и их реплики распределены по различным узлам;

· узлы связаны между собой сетевыми соединениями;

· работа с данными на каждом узле управляется локальной СУБД.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

71. Обработка распределенных запросов. Преимущества и недостатки РаСУБД

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

· к какому фрагменту следует обратиться;

· какую копию фрагмента использовать, если его данные реплицируются;

· какое из местоположений должно использоваться.

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

Преимущества РаСУБД:

1. Отражение структуры организации.

2. Разделяемость и локальная автономность.

3. Повышение доступности данных.

4. Повышение надежности.

5. Повышение производительности.

6. Экономические выгоды.

7. Модульность системы.

Недостатки РаСУБД:

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

2. Увеличение стоимости. Увеличение сложности означает и увеличение затрат на приобретение и сопровождение РаСУБД.

3. Проблемы защиты. В централизованных системах доступ к данным легко контролируется. Однако в распределенных системах требуется организовать контроль доступа не только к данным, реплицируемым на несколько различных узлов, но и защиту сетевых соединений самих по себе.

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

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

6. Недостаток опыта. Еще не накоплен необходимый опыт промышленной эксплуатации распределенных систем, сравнимый с опытом эксплуатации централизованных систем.

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

8. Сложность управления и обусловленная этим потенциальная опасность потери целостности данных.