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

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

В большинстве случаев проектная экспертиза проводится как минимум несколько раз в течении жизненного цикла, в частности:

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

2) по окончании детального проектирования совокупности;

3) по окончании реализации, но для начала эксплуатации совокупности;

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

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

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

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

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

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

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

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

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

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

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

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

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

Главные этапы последовательности проектирования распределенной базы данных заключаются:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

02 — Базы данных. Архитектура распределенной базы данных

Похожие статьи:

Понравилась статья? Поделиться с друзьями:
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!:

Adblock
detector