Архитектура разработка распределенных СУБД

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

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

1.4 Разработка распределенных рБД

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

1)     Фрагментация. Любое отношение может быть разделено на некоторое количество частей, называемых фрагментами, которые затем распределяются по различным узлам. Существуют два основных типа фрагментов: горизонтальные и вертикальные. Горизонтальные фрагменты представляют собой подмножества строк, а вертикальные — подмножества атрибутов.

2)     Размещение. Каждый фрагмент сохраняется на узле, выбранном с учетом оптимальной схемы их размещения.

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

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

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

      частота выполнения транзакции;

      узел, на котором выполняется транзакция;

      требования к производительности транзакций.

Качественная информация может включать сведения о выполняемых транзакциях:

      используемые отношения, атрибуты и строки;

      тип доступа (чтение или запись);

      предикаты операций чтения.

Определение и размещение фрагментов по узлам выполняется для достижения следующих стратегических целей.

      Локализация ссылок.

      Повышение надежности и доступности.

      Приемлемый уровень производительности.

      Минимизация расходов на передачу данных.

1.5 12 правил Дейта для распределенных СУБД

В 1987 г. К. Дейт опубликовал свои правила для распределенных баз данных.

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

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

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

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

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

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

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

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

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

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

11. Независимость от сети. Узлы могут быть связаны между собой с помощью множества разнообразных сетевых и коммуникационных средств. Многоуровневая модель, присущая многим современным информационным системам (например, семиуровневая модель OSI, модель TCP/IP, уровни SNA и DECnet), обеспечивает решение этой проблемы не только в среде РаБД, но и для информационных систем вообще.

12. Независимость от СУБД. Локальные СУБД должны иметь возможность участвовать в функционировании РаСУБД.

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

Выводы

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

Система управления распределенной базой данных определяется как программная система, которая позволяет управлять базой данных таким образом, чтобы ее распределенность была прозрачна для пользователей.

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

Существует множество альтернатив распределенной обработки. Наиболее популярна в настоящее время архитектура клиент-сервер.

Заключение

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

Система управления распределенной базой данных определяется как программная система, которая позволяет управлять базой данных таким образом, чтобы ее распределенность была прозрачна для пользователей.

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

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

Существует множество альтернатив распределенной обработки. Наиболее популярна в настоящее время архитектура клиент-сервер. Более распределенной и более гибкой является архитектура типа много-клиентов/много-серверов.

В истинно распределенной СУБД клиентские и серверные машины не различаются.

Список использованных источников

1.                              Грофф Дж.Р. SQL – Полное руководство. Киев: BHV, 2001. – 798 с.

2.                              Коннолли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд.: пер. с англ.:Уч. Пособ. –М.: Издательский дом "Вильямс", 2000. –1120 с.: ил.

3.                              Интернет-ресурс: WIKIPEDIA.

Allbest.ru