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

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

END

ROLLBACK TRANSACTION

BEGIN

FOR INSERT, UPDATE

ON property_for_rent

CREATE TRIGGER staff_not_handling_too_much

GROUP BY sno

FROM property_for_rent

CHECK (NOT EXIST (SELECT sno

HAVING COUNT(*)>10))

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

AS IF ((SELECT COUNT(*) FROM property_for_rent p, WHERE

p.sno = INSERTED.sno) > 10)

PRINT "Данный работник уже отвечает за 10 объектов"

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

В некоторых системах отсутствует поддержка реализации некоторых или всех типов бизнес-правил. В этом случае соответствующие действия должны быть реализованы непосредственно в приложениях. Например, существует очень мало (если они вообще есть) реляционных СУБД, которые позволяют реализовать ограничения по времени — допустим, такое: "В 17.30 последнего рабочего дня каждого года выполняется архивирование всех строк, относящихся к объектам, проданным в течение этого года, после чего данные записи удаляются".

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

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

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

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

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

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

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

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

Дата добавления: 2014-01-07