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

Существует множество довольно известных методов построения программного обеспечения для проектирования баз данных. К примеру, для этого можно использовать нисходящее проектирование, которое всецело подходит для структуры базы данных. На исходной вступительной стадии концептуальная модель, которая предоставляет для использования все возможные элементы данных и координацию конкретной области, постепенно формируется в системно-ориентированную структуру базы данных. Процесс развития проектирования очень сильно структурирован, что в свою очередь хорошо сказывается на конечном результате. Любой этап процесса проектирования обязательно завершается хорошо определенным результатом. А в том случае, если вдруг конечный результат не удовлетворяет изначально запрошенных требований или каким-то системным ограничениям возможно итеративное повторение предыдущих этапов. Но кроме этого при необходимости можно накладывать дополнительные требования [18]. Благодаря этому проектировщик может в дальнейшем модифицировать проектные решения на любом предыдущем этапе. В действительности при реализации затраты на само проектирование сильно увеличиваются. При этом любые проектные решения заново анализируются после того, как отдельные решения уже были осуществлены. Именно поэтому использование итерации наиболее продуктивно на тех этапах, которые предшествуют этапу реализации. Все же применение итераций может сильно снизить итоговую стоимость реализации базы данных, но это применение одновременно с этим затрудняет достижение одной из самых главных целей при проектировании - воспроизводимости. Однако на сегодня итерация представляет собой самое нужное, важное и полезное средство. Итерацию можно использовать на всех этапах процесса проектирования. Также при процессе проектирования базы данных возможно применение многошаговой методологии экспертной оценки проекта или проектной экспертизы, которая содержит в себе такие методы, как сквозной структурный контроль базы данных и прикладное программное обеспечение [18;21]. Когда системы баз данных применяют стратегию, которая подходит для универсальных информационных систем, то очень эффективно применение проектной экспертизы. Главная и единственная цель экспертизы заключается в обнаружении ошибок при системном проектирования и их исправлении на самых ранних стадиях жизненного цикла, для снижения затрат, которые идут на разработку системы.

Проектная экспертиза осуществляется как минимум четыре раза за весь жизненного цикла проектирования:

1) после оценки требований и проектирования информационной структуры, то есть после концептуального проектирования;

2) после четко разработанного проектирования системы;

3) после эксплуатации системы и ее исполнения;

4) после начала эксплуатации, в то время как в систему вложена полная информация насчет эксплуатационных характеристик.

Средства для проектирования и оценочные критерии

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

Оценочные критерии в виде средств проектирования как таковые нужны, чтобы из всевозможных структур базы данных выбрать подходящую. Почти все значительные проблемы при проектировании базы данных происходят из-за неверного представления о том, что представляет собой проектирование базы данных. В наши дни и в ближайшее будущее нечеткость выбора оценочных критериев будет самым слабым местом при проектировании баз данных [16].

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

Средства описания

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

В методологии проектирования имеется три главных раздела описательных средств. К первому разделу относится язык описания данных ЯОД, который входит в состав системы управления базой данных. Этот язык применяется для характеристики итогового результата в процессе проектирования реализации.

Второй раздел несет в себе описание первоначальной информации. На сегодняшний день всевозможные средства, которые необходимы для сбора и анализа информации, сходны в одном, а именно в том, что они организовывают форматы для спецификации информации типа ISP и UP. Кроме этого они реализуют основные проверки совместимости данных [14].

Третий раздел описательных средств необходим для представления результатов промежуточных этапов. Он является промежуточным между ЯОД и описанием первоначальной информации.

Любые средства проектирования и оценочные критерии используются на каждом этапе разработки. Применение количественных критериев (время ответа на запрос, затраты на обновление, стоимость памяти, время на формирование, стоимость преобразования) содействует формированию противоречивых критериев относительно друг друга [19]. Одновременно с этим имеется огромное множество критериев оптимальности, которые являются неизмеримыми свойствами, при этом они почти не выражаются в количественном выражении или как целевая функция.

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

В распределенных системах баз данных логически не дробимая база данных может расчленяться и размещаться во всей сети для увеличения работоспособности системы. Расчленение и размещение базы данных без бдительного централизованного планирования зачастую создает беспорядок и несовместимость при применении базы данных [18].

Существует 6 главных этапов проектирования распределенной базы данных:

1) формулирование и анализ требований;

2) концептуальное проектирование;

3) проектирование реализации;

4) расчленение базы данных;

5) размещение базы данных;

6) физическое проектирование.

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

Этап концептуального проектирования состоит из описания и синтеза различных информационных запросов пользователей в исходный проект баз данных. На данном этапе реализуется высокоуровневое отображение данных запросов. Хорошим примером такого представления является диаграмма «сущность-связь». Эта диаграмма состоит из определенного набора сущностей, представляющего или моделирующего некое множество сведений, которое специфицировано в требованиях. Связи, существующие между сущностями, представляют функциональные аспекты информации, которые представлены сущностями.

Имеется небольшое количество подходов для построения диаграмм типа «сущность-связь». Единым для всех типов подходов является набор из четырех главных проектных решений или шагов:

1) определение сущностей;

2) определение атрибутов сущностей;

3) идентификации ключевых атрибута сущностей;

4) определение связей между сущностями.

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

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

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

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

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

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

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

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

2) проблема, связанная с формированием инфологической структуры информационного фонда распределенной базы данных, которая ориентирована на решение всего комплекса задач выбранной системы расчетов;

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

4) организационно-правовая проблема, заключающаяся в надежной защите данных и соблюдении юридических норм доступа к базам данных, их заполнения, изменения и уничтожения.

Заключение

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

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

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

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