Лекция: Декомпозиция предметной области.

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

Отметим, что этапы 1, 2, 3 и 6 подобны этапам при проектировании централизованной базы данных. Поэтому рассмотрим только этапы 4 и 5 (этап расчленения базы данных и этап размещения). Этап расчленения базы данных связан с расчленением глобальной базы данных и синтезом различных приложений на основе модели.

Как показано на рисунке, существуют три класса выходных данных этапа расчленения: совокупность расчленения частей базы данных (разделов), размер каждого раздела, модели и частоты использования приложений. На этом этапе проектирования исходная глобальная база данных расчленяется на множество подфайлов {F1,..., Fn}. Требуется, чтобы расчлененные подфайлы содержали в точности все сведения, имевшиеся в глобальной базе данных. Помимо требования о сохранении информации часто требуется совместимость ограничений на разделы базы данных. Совместимость структуры базы данных дает возможность проектировать для всех структурно допустимых разделов некие составляющие блоки. Составляющие блоки могут быть и столь малыми, как кортежи (экземпляры записей) в реляционной модели данных, и столь большими, как связанные компоненты (посредством связи владелец — член) в сетевой модели данных. Существуют два момента, которые накладывают ограничения на процесс формирования разделов из составляющих блоков. Это допустимый размер и производительность. При оценке производительности должны учитывать также два основных фактора: время отклика и надежность системы. Необходимо объединять в подфайл такие часто используемые совместно записи, чтобы он (будучи размещен с учетом частоты использования) улучшал характеристики отклика системы. Необходимо пытаться получить требуемый уровень надежности, используя по возможности меньшую кратность дублирования. Каждый подфайл в расчлененной базе данных должен выбираться как неделимая единица размещения данных. Более того, если каждая ЭВМ в системе имеет фиксированный объем памяти, это будет являться определенным ограничением на класс допустимых расчленений. Простой пример подобного ограничения размер подфайла не может превышать максимальный объем памяти, имеющейся в узле. На этапе Модели и частоты использования приложений проводится анализ того, как приложения базы данных используют возможные разделы базы данных. Связь между разделом базы данных и приложениями характеризуются идентификатором типа приложения, идентификатором узла сети, создающего приложение (т. е. транзакцию), частотой использования приложения и моделью приложения. Модели приложений могут быть классифицированы следующим образом: Приложения, использующие единственный файл. Приложения, использующие несколько файлов: приложения, допускающие независимую параллельную обработку; приложения, допускающие синхронизированную обработку. Стоимость обработки и побочные эффекты синхронизации вместе с расчленением и размещением разделов оказывают важное влияние на производительность базы данных. Понимание этой взаимосвязи является определяющим в процессе проектирования распределенных баз данных. Поэтапная методика размещения отличается от классического подхода, по меньшей мере, в двух аспектах: Расчленение базы данных является неотъемлемой частью решения задачи размещения. При классическом методе решения считается, что расчленение базы данных задано. На этапе расчленения базы данных мы используем столько ограничений, сколько нужно, чтобы сузить класс допустимых расчленений. Тем не менее, в общем случае на этапе 4 (этап расчленения БД) выбор единственного расчленения невозможен. Для того чтобы получить лучшую структуру, этап 5 (размещение БД) повторяется для каждого возможного варианта расчленения, полученного на этапе 4. Этот процесс длится до тех пор, пока не будет получен удовлетворительный результат или не будут исчерпаны все допустимые расчленения. При классическом подходе предполагается, что приложения обращаются лишь к единственному файлу. В отличие от этого предположение о транзакциях, являющихся результатом этапа 4, должно учитывать приложения, использующие несколько файлов. Для такого обобщения требуется новая модель. Размещение распределенной базы данных является многовариантной задачей. Количество возможных вариантов реализации расчлененной или смешанной базы данных огромно. Для того чтобы выбрать наиболее подходящую стратегию распределения данных, необходимо еще до выбора СУБД провести оценку пользовательских и системных требований, если, конечно, это возможно. Могут быть также определены допущения, упрощающие сетевую систему управления базой данных, например, что запросы на обновление исходят только из одного узла или допустимость временного рассогласования базы данных. В рамках существующих четырех стратегий распределения данных допущения такого рода будут иметь большое влияние на выбор конкретной системы управления сетевой базы данных, которая в свою очередь оказывает влияние на фазу проектирования распределенной базы данных. При этом необходимо иметь информацию о данных, узлах сети, приложениях, их связях, а также требования, предъявляемые ко времени отклика и надежности, и ограничения, накладываемые аппаратными и программными средствами сети. Может оказаться необходимым выполнять при проектировании итерации до достижения приемлемого компромисса. После того как выбраны стратегия расчленения и конкретная система управления базой данных, встает задача рационального размещения данных по узлам сети. На этой стадии предполагается, что логическая структура базы данных, или схема, фиксирована. Размещение данных по узлам сети является сравнительно простой задачей для двух из четырех стратегий размещения данных. При использовании дублированной стратегии для каждого узла существуют лишь два варианта: размещать или не размещать полную копию базы данных. Некая комбинация из требований пользователей, перечня альтернатив и здравого смысла может решить много проблем или, по меньшей мере, уменьшить количество альтернатив настолько, чтобы каждую из них в дальнейшем можно было проверить. Более трудной является задача размещения данных по узлам сети при стратегии расчленения и гораздо более трудной для смешанной стратегии. В случае стратегии расчленения следует решить следующие вопросы: как расчленить базу данных на логические фрагменты, как разместить каждый логический фрагмент в конкретном узле (т. е. один хранимый фрагмент). Если принимается смешанная стратегия, то решение становится более сложным, так как каждый фрагмент может быть размещен в любом количестве узлов (несколько хранимых фрагментов). Это эквивалентно принятию решения, какая часть базы данных должна быть расположена в каждом узле. Количество перестановок логических и хранимых фрагментов растет весьма быстро. Это является одной из причин того, что целью проектирования часто является рациональная, а не оптимальная схема размещения.