ФОРМАЛИЗАЦИЯ ПРОЦЕССА ПРОЕКТИРОВАНИЯ РАСПРЕДЕЛЕННЫХ БАЗ ДАННЫХ

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

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

При описании целей и изучение основных задач, следует принимать во внимание физические параметры такие как: топологию сети, нагрузку и конфигурацию серверов, количество узлов, удобство администрирования, пропускную способность сети и другие важные параметры системы. Рассмотрение и анализ параметров применяется для выявления необходимых требований к РаспБД [2]. Под требованиями следует понимать экономические выгоды, целесообразность проектирования РаспБД для конкретных целей, проектирование на основе уже созданных локальных БД или с нуля. Требования обязательно должны нести в себе ограничения, которые гарантируют безопасность, надежность, эффективность и уровень достижимости технологии.

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

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

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

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

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

4. Физическая реализация. Этап реализации заключается в выборе способа и механизма построения РаспБД. Этот этап проектирования можно представить в виде жизненного цикла РаспБД, который состоит из фаз представленных на рис. 1.

Рисунок 1. Жизненный цикл проектирования РаспБД

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

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

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

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

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

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

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

Список литературы:

1. Дейт К. Дж. Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом "Вильяме" 2005. — 1328 с.
2. Крёнке Д. Теория и практика построения баз данных. 8-е изд. — СПб.: Питер, 2003 - 800 с.
3. Таненбаум Э., Стеен M. Ван Распределенные системы. Принципы и парадигмы – СПб.:Питер, 2003 – 877с.