Основы проектирования распределенной базы данных

Существует множество довольно известных методов построения программного обеспечения для проектирования баз данных. К примеру, для этого можно использовать нисходящее проектирование, которое всецело подходит для структуры базы данных. На исходной вступительной стадии концептуальная модель, которая предоставляет для использования все возможные элементы данных и координацию конкретной области, постепенно формируется в системно-ориентированную структуру базы данных. Процесс развития проектирования очень сильно структурирован, что в свою очередь хорошо сказывается на конечном результате. Любой этап процесса проектирования обязательно завершается хорошо определенным результатом. А в том случае, если вдруг конечный результат не удовлетворяет изначально запрошенных требований или каким-то системным ограничениям возможно итеративное повторение предыдущих этапов. Но кроме этого при необходимости можно накладывать дополнительные требования [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) организационно-правовая проблема, заключающаяся в надежной защите данных и соблюдении юридических норм доступа к базам данных, их заполнения, изменения и уничтожения.

Заключение

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

В системе распределенных баз данных данные распределены между несколькими (возможно, территориально разобщенными) ЭВМ и обеспечены соответствующие возможности для управления этими разделенными частями.

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

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

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

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

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

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

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

Поиск по сайту: