Документирование проекта реализации бизнес-правил

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

Этап 5. Проектирование физического представления базы данных

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

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

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

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

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

Однако ни один из этих факторов не является самодостаточным. Как правило, разработчик вынужден жертвовать одним из показателей ради другого, чтобы достичь оптимального баланса. Например, увеличение объема хранимых данных может вызвать увеличение времени ответа системы или уменьшение пропускной способности транзакций. Исходный вариант физического проекта базы данных не следует понимать как нечто статическое, но надо рассматривать как средство оценки возможного уровня производительности системы. После реализации исходного варианта проекта необходимо вести наблюдение за показателями работы системы и сообразно полученным результатам выполнять ее настройку с целью улучшения показателей работы и отражения изменяющихся требований пользователей (этап 7). Многие типы СУБД предоставляют в распоряжение администратора базы данных (Data Base Administrator - DBA) комплект утилит, предназначенный для контроля за функционированием системы и ее настройки. Позже мы узнаем, что существуют определенные структуры организации внешней памяти, позволяющие эффективно загружать в базу большие объемы данных, но мало пригодные для других целей. Другими словами, вначале имеет смысл выбрать такие структуры хранилищ, которые будут весьма эффективны при массовой загрузке данных в процессе создания базы, после чего их можно будет заменить другими структурами, позволяющими ее эффективно эксплуатировать.

И опять-таки диапазон выбора возможных типов организации файлов зависит от целевой СУБД, поскольку различные системы поддерживают разные наборы допустимых структур хранения информации. Очень важно, чтобы разработчик физического проекта базы данных имел полное представление о всех типах структур данных, поддерживаемых целевой СУБД, а также обо всех особенностях использования этих структур в системе. В частности, желательно, чтобы разработчик ясно понимал принципы работы оптимизатора запросов системы. Например, могут возникнуть ситуации, в которых оптимизатор запросов не будет использовать вторичные, индексы, даже если они будут доступны. В результате простое добавление вторичного индекса не позволит повысить эффективность обработки запросов, а лишь вызовет дополнительную бесполезную нагрузку на систему. Некоторые СУБД предоставляют пользователям средства ознакомления с выбранной оптимизатором стратегией выполнения отдельного запроса или операции обновления. Эта функция носит название Query Execution Plan (QPE) (получение плана выполнения запроса). Например, СУБД DB2 имеет утилиту EXPLAIN, СУБД Oracle — диагностическую утилиту EXPLAIN PLAN, а СУБД INGRES поддерживает интерактивную QРЕ-функцию. Если выполнение запроса происходит медленнее, чем это предполагалось, имеет смысл воспользоваться подобным инструментом, чтобы определить причины замедления работы. Полученные данные помогут найти альтернативную стратегию, которая позволит увеличить скорость обработки запроса. Обработка запросов будет подробно обсуждаться в главе 18, "Обработка запросов".