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

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

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

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

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

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

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

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

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

Основные свойства распред. СУБД:

1)прозрачность располож. данных;

2)гетерогенность системы;

3)прозрачность сети(система должна работать в условиях гетерогенной сети);

4)поддержка распред. запросов, изменений, транзакций(пользователь должен иметь возможность выполнять запросы, изменения и транзакции);

5)безопасность(обеспечить защиты всей РБД от несанкц-ого доступа);

6)универсальность доступа(единая методика доступа ко всем данным).

Могут возникать проблемы:

1)снижение произ-ти за счёт несбалан-ти и низкой пр-ти сетей передачи данных;

2)длительная блокировка данных при выполнении распре-ной транзакций;

3)необходимость обеспеч. совместимости данных стандартного типа, для хранения кот. в разных сис-мах используются разл. форматы и кодировки;

4)неэффект. выбор схемы размещения сис-ных каталогов;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для обеспечения целостности РаСУБД – 2 механизма:

-механизм пофазной фиксации синхронный захват всех объектов данных, к кот. обращ-ся или происх-ит изменения на всех серверах, либо осущ-ся откат в случае хотя бы 1 ошибки)

-механизм асинхронного тиражирования (обраб-ка данных осущ-ся локально, а распред-ые данные копир-ся на тот сервер, где они должны использов-ся)

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

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

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

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

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

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

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

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

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

1. Повышение сложности.

2. Увеличение стоимости.

3. Проблемы защиты, связ-ые с необх-ю контролир-ть доступ к данным и защитой сетевых соединений

4. Усложнение контроля за целостностью данных.

5. Недостаточная стандартизация, затрудняющая преобраз-е системы

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

7. Усложнение процедуры проектирования БД.

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

75.Типы интерфейсов доступа к БД. ODBC (Open Database Connectivity) —программный интерфейс доступа к БД, разраб-ый фирмой Microsoft. В начале 1990 г. существовало несколько поставщиков БД, каждый из которых имел собственный интерфейс. Если приложению было необходимо общаться с несколькими источниками данных, для взаимодействия с каждой из баз данных было необходимо написать свой код. Для решения возникшей проблемы Microsoft и ряд других компаний создали стандартный интерфейс для получения и отправки источникам данных различных типов. Этот интерфейс был назван ODBC, или открытая связь с базами данных. C помощью ODBC прикладные программисты могли разрабатывать приложения для использования одного интерфейса доступа к данным, не беспокоясь о тонкостях взаимодействия с несколькими источниками. MFC усовершенствовала ODBC для разработчиков приложений. Истинный интерфейс ODBC является обычным процедурным API. Вместо создания простой оболочки процедурного API, разработчики MFC создали набор абстрактных классов, представляющих логические сущности в БД.

При применении ODBC требуется помнить, что данная технология доступа к данным не рассчитана на работу с большим числом клиентов. ADO — интерфейс программирования приложений для доступа к данным, разработанный компанией Microsoft и основанный на технологии компонентов ActiveX. ADO позволяет представлять данные из разнообразных источников в объектно-ориентированном виде. JDBC — платформенно-независимый промышленный стандарт взаимодействия Java-приложений с различными СУБД, реализованный в виде пакета java.sql. JDBC основана на концепции так называемых драйверов, позволяющих перемещение столбца· выделение столбца; получать соединение с БД по специально описанному URL. Драйверы могут загружаться динамически. Загрузившись, драйвер сам регистрирует себя и вызывается автоматически, когда программа требует URL, содержащий протокол, за который драйвер отвечает.

JDBC API содержит два основных типа интерфейсов: первый - для разработчиков приложений и второй (более низкого уровня) - для разработчиков драйверов. Соединение с БД описывается классом, реализующим интерфейс java.sql.Connection. Имея соединение с БД можно создавать объекты типа Statement, служащие для исполнения запросов к базе данных на языке SQL.

Дата добавления: 2015-10-21