6. Проектирование оптимальной логической и физической структуры информационной системы.

6.1. Методы решения задачи проектирования структуры и эскизная оценка проекта структуры ис

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

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

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

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

• Количество обращений к логическим записям (LRA)

Количество обращений ко всем типам записи приложения p дается следующим выражением: , (6.1)

где N – число SQL-запросов к базе данных, М – число таблиц в БД, – матрица средних значений выбираемых по запросу информационных элементов, – матрица средних значений корректируемых экземпляров информационных элементов, =1, если i-я SQL-команда обращается к k-й таблице.

Выражение в квадратной скобке при этом дает число обращений к k-ой таблице БД, которое мы обозначим как LRA_pk. Используя частоту обращения к k-ой таблице БД за единицу времени – ξ_pk, полное количество обращений к базе данных в единицу времени равно

, (6.2)

где P – общее количество приложений для данной базы данных.

• Объем передачи данных

Объем передачи данных (в байтах) для приложения p задается выражением

, (6.3)

где RSZ_k –средний размер логической записи k в байтах. Объем передачи данных в единицу времени (в байтах) равен

(6.4)

Здесь под ξ_p понимается частота обращения к таблицам для приложения p.

• Объем памяти .

Объем памяти (в байтах) равен

, (6.5)

где NREC_k – количество экземпляров k-го типа записей в базе данных.

Объем памяти для указателей (в байтах) равен

, (6.6)

где PS – длина указателя (в байтах) и NPTR_j— среднее количество указателей, хранимых совместно с записью типа j.

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

• найти уникальный экземпляр записи типа j;

• найти все экземпляры записи типа j (связанные с исходной записью типа k);

• найти некоторое подмножество экземпляров записей типа j, удовлетворяющих определенному булевскому критерию. Для этих типов (или классов) выборки величина LRA обычно равна соответственно 1, NRECR_j или NRECR_j/2, где NRECR_j – среднее количество экземпляров записей типа j в определенной связи (обычно порожденных записей для соответствующей исходной) либо мощность отношения.

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

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

Прагматический подход подразумевает синтез схемы БД, основанный на использовании связей между сущностями. В этом случае типы сущностей определяют типы записей, а связи типа 1:М определяют типы наборов, содержащих соответствующие записи. Тогда элементы данных группируются по типам записей в соответствии с СУБД-независимой диаграммой сущностей. Это стандартный путь работы с использованием CASE-технологий. Несмотря на очевидную простоту и прозрачность этого подхода, степень оптимальности созданной таким образом структуры в смысле определенного критерия эффективности зависит от мастерства разработчика и в общем случае ее трудно оценить.

Более эффективным подходом является разбиение атрибутов сущностей на группы типов записей или объединение атрибутов нескольких объектов в один тип записи. Этот метод основан на анализе информационной матрицы F, размерности N´N, где N – количество элементов в информационной структуре, а элемент F_ij соответствует частоте, с которой атрибуты i и j обрабатываются вместе. Большие частоты использования указывают на пары атрибутов, которые следует поместить в один тип записи. Недостаток этого метода очевиден – большая частота использования одного или нескольких атрибутов может привести к избыточности в хранении данных.

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

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

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