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

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

6.3. Целевая функция и ограничения для общей задачи построения ис на основе рбд.

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

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

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

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

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

(6.7)

Здесь – частота использования p-ой таблицы в запросе k-ого пользователя; ν_kr – матрица прикрепления пользователей к локальным серверам: ν_kr=1, если k-ый пользователь прикреплен к r-тому серверу, и ноль в противоположном случае; – матрица использования запросов пользователями: , если k-ый пользователь использует p-ый запрос, и ноль в противоположном случае; – количество блоков информации, содержащихся в i-ой записи и передаваемой по p-ому запросу пользователя.

Временные характеристики выполнения заданий пользователей имеют следующий смысл:

– время ожидания доступа к БД и поиска требуемых записей;

– время обмена между дисковой и оперативной памятью;

– время формирования одной подзадачи (запроса) к локальной БД;

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

– время выбора маршрута и установления виртуального соединения;

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

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

Переменные x, y и z имеют следующий смысл.

(6.8)

(6.9)

(6.10)

где - матрица использования p-ой таблицы k-ым пользователем: =1, если таблица p используется пользователем k, и ноль в противоположном случае.

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

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

(6.11)

Задача поиска минимума целевой функции (6.3) по x_it, y_tr имеет ряд ограничений. Они включают:

• ограничение на стоимость хранения информации;

• ограничение на время выполнения заданий по корректировке и обновлению информации;

• ограничение на число атрибутов в составе таблицы;

• ограничение на однократность включения атрибутов в таблицы;

• ограничение на длину формируемой логической записи;

• ограничение на число синтезируемых типов записей для r-ого локального сервера БД;

• ограничение на размещение типов записей в распределенной БД;

• ограничение на объем доступной дисковой памяти на локальных серверах БД;

• ограничение на количество размещаемых в сети копий типов записей;

• ограничение на пропускную способность каналов связи;

• ограничение на оперативность получения определенной информации по запросу k-го пользователя (p=const, k=const);

• ограничение на прикрепление пользователей к локальным серверам;

• ограничение на несанкционированный доступ пользователей к заданной информации;

• ограничение на надежность доступа к данным при выполнении запросов;

• ограничение на надежность доступа к данным при выполнении корректировок;

• ограничение на надежность доступа к заданному серверу для всех пользователей СУБД.

Целевая функция в случае выполнения множества запросов пользователей в параллельном режиме имеет следующий вид:

(6.12)