Неоднородные базы данных, проблемы эксплуатации неоднородных баз данных.

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

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

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

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

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

12 Распределенные базы данных: способы распределения данных между узлами.

РБД состоит из набора узлов, связанных коммуникационной сетью, в которой:

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

Распределённую систему баз данных можно рассматривать как партнёрство между отдельными локальными СУБД на отдельных локальных узлах.

Каталог распред системы:

1.Централизованный катал (весь каталог хранится в одном месте в центр узле)

2.Полноценный репликационный каталог(на каждом узле хранится полный катал)

3.Секционированный (на каждом узле хранится свой собственный системный каталог,а полный сетевой каталог получаем при объединении)

4.Комбинир 1 и 3 (на одном узле хранится полный , на другом свой собственный)

Распределение осуществл с помощью фрагментации. Отношения могут быть фрагментированны на вертикальные и горизонтальные разделы. При горизонтальной фрагментации отношение делается с помощью операции селекции или предиката фрагм. При верт - с помощью отношения проекции.

За счет фрагментации данные можно хранить там, где они чаще используются , что позвол снизить время на передачу данных и

уменьшить размнер отношений, тем самым повысив скорость выполн запроса.

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

1.Синхронная

Самый высокий уровень надежности

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

2.Асинхр – Изменение данных сохраняется только на сервере, где выполняется транзакция. Сервер заботится о передаче данных всем остальным серверам. Обновление спустя некот время. Существует момент времени, когда репликации не идентичны.

3.Репликация по расписанию: В периоды между реплик данные могут расходиться.