Физическое проектирование базы данных
Перенос глобальной логической модели данных в среду целевой СУБД
Самым первым заданием на этапе физического проектирования баз данных является преобразование отношений, созданных на основе глобальной логической модели данных, в такую форму, которая может быть реализована в среде целевой СУБД. Первая часть этого процесса предусматривает проверку информации, собранной на этапе логического проектирования базы данных и помещенной в словарь данных. Вторая часть процесса заключается в использовании этой информации для разработки проекта основных отношений.
Проектирование основных отношений
Приступая к физическому проектированию, прежде всего необходимо проанализировать и хорошо усвоить информацию об отношениях, собранную на этапе построения логической модели базы данных. Определение каждого выделенного в глобальной логической модели данных отношения включает следующие элементы:
имя отношения;
список простых атрибутов, заключенный в круглые скобки;
определение первичного ключа и (если таковые существуют) альтернативных (АК) и внешних (FK) ключей;
список производных атрибутов и описание способов их вычисления;
определение требований ссылочной целостности для любых внешних ключей.
Для каждого атрибута в словаре данных должна присутствовать следующая информация:
определение его домена, включающее указание типа данных, размерность внутреннего представления атрибута и любые требуемые ограничения на допустимые значения;
принимаемое по умолчанию значение атрибута (необязательно);
допустимость значения NULL для данного атрибута.
Теперь необходимо принять решение о способе реализации основных отношений. Это решение зависит от типа выбранной целевой СУБД - при определении основных отношений некоторые системы предоставляют больше возможностей, чем другие. Подготовленный проект основных отношений должен быть подробно описан в сопроводительной документации с указанием причин, по которым был выбран данный конкретный проект. В частности, необходимо указать, почему был выбран именно этот подход, если есть целый ряд других вариантов.
Разработка способов получения производных данных
Производными, или расчетными называются атрибуты, значения которых можно определить с использованием значений других атрибутов. На этапе физического проектирования базы данных необходимо определить, должен ли производный атрибут храниться в базе данных или вычисляться каждый раз, когда в нем возникает необходимость. Проектировщик должен рассчитать следующее:
дополнительные затраты на хранение производных данных и поддержание их согласованности с реальными данными, на основе которых они вычисляются;
затраты на вычисление производных данных, если их вычисление выполняется по мере необходимости.
Из этих двух вариантов выбирается наименее дорогостоящий с учетом требований к производительности. В процессе проектирования необходимо обеспечить, чтобы эти изменения происходили в каждом из указанных случаев и количество учитываемых объектов оставалось правильным, поскольку это гарантирует целостность базы данных. Если запрос указанного типа выполняется часто или считается очень важным с точки зрения производительности, производный атрибут более целесообразно хранить в базе данных, а не вычислять при каждом обращении к его значению.
Реализация ограничений предметной области
Обновление информации в отношениях может регламентироваться ограничениями предметной области, регулирующими выполнение тех реальных транзакций, которые связаны с проведением таких обновлений. Способ реализации указанных ограничений опять-таки будет зависеть от типа выбранной целевой СУБД, поскольку одни системы для реализации ограничений предметной области предоставляют более широкие возможности, чем другие. Как и на предыдущем этапе, если целевая СУБД поддерживает стандарт языка SQL, то реализовать определенные типы ограничений будет намного проще. Альтернативным методом реализации ограничений является применение триггеров. В некоторых системах отсутствует поддержка части или даже всех ограничений предметной области и поэтому такие ограничения приходится предусматривать непосредственно в самом приложении.
Проектирование физического представления базы данных
Существует несколько показателей, которые могут быть использованы для оценки достигнутой эффективности.
Производительность выполнения транзакций. Этот показатель представляет собой количество транзакций, которые могут быть обработаны за заданный интервал времени.
Время ответа. Характеризует временной промежуток, необходимый для выполнения одной транзакции.
Дисковая память. Разработчик должен стремиться минимизировать объем используемой дисковой памяти.
Однако ни один из этих факторов не является самодостаточным. Как правило, разработчик вынужден искать компромисс между этими показателями для достижения приемлемого баланса.
Определение понятия системных ресурсов
Чтобы достичь высокой производительности системы, разработчик физического проекта базы данных должен знать, каким образом взаимодействуют между собой и влияют на производительность системы следующие четыре основных компонента аппаратных средств.
Оперативная память. Доступ к данным в оперативной памяти осуществляется намного быстрее, чем к данным во внешней памяти.
Процессор. Важнейшим условием эффективной работы этого компонента является предотвращение конкуренции за право его использования, что обычно сопровождается переводом процессов в состояние ожидания.
Дисковый ввод-вывод. Как правило, изготовители дисковых устройств указывают рекомендуемое количество операций ввода-вывода в секунду.
Файлы операционной системы должны быть отделены от файлов базы данных.
Основные файлы базы данных должны быть отделены от индексных файлов.
Журнал восстановления должен быть отделен от остальной части базы данных.
Сеть. Сеть может стать узким местом всей системы при чрезмерном возрастании сетевого трафика или большом количестве сетевых коллизий.
Каждый из этих ресурсов способен оказывать влияние на остальные системные ресурсы.
Анализ транзакций
Для успешного планирования каждой транзакции необходимо знать следующее:
транзакции, выполняемые наиболее часто и оказывающие существенное влияние на производительность;
транзакции, наиболее важные для работы организации;
периоды времени на протяжении суток/недель, в которые нагрузка базы данных возрастает до максимума (называемые периодами пиковой нагрузки).
Эта информация используется для определения компонентов базы данных, которые могут вызвать проблемы производительности. Кроме того, необходимо определить такие характеристики транзакций высокого уровня, как атрибуты, модифицируемые в транзакциях обновления, или критерии, которые служат для ограничения количества строк, возвращаемых по запросу. Эта информация используется для определения наиболее подходящей файловой организации и создания индексов.
Во многих случаях проанализировать все ожидаемые транзакции просто невозможно, поэтому необходимо тем или иным образом выбрать наиболее "важные" из них. Существует эмпирическое правило, согласно которому выполнение около 20% наиболее активных запросов пользователей создает примерно 80% общей нагрузки на базу данных. Это правило "80/20" может использоваться как рекомендация по проведению анализа. Для определения того, какие из транзакций подлежат детальному анализу, воспользуемся таблицей соответствия транзакций и отношений, в которой показаны отношения, доступ к которым происходит при выполнении каждой транзакции, а также диаграммой частоты выполнения транзакций, которая схематически показывает отношения, вероятность использования которых в транзакциях наиболее высока. Для выделения областей, которые с наибольшей вероятностью могут явиться источником проблем, необходимо выполнить перечисленные ниже действия.
Подготовка схемы соответствия путей выполнения транзакций и отношений
Этапы 1.8, 2.4 и 3.2 методологии концептуального/логического проектирования базы данных предусматривают оценку моделей данных для определения того, поддерживают ли они все транзакции, необходимые для работы пользователей; для этого устанавливается соответствие между путями выполнения транзакций и сущностями/отношениями. Если при такой проверке используется схема путей выполнения транзакций, то в дальнейшем эта схема позволяет определить, доступ к каким отношениям происходит наиболее часто.
Анализ использования данных
После определения наиболее важных транзакций подробно анализируется каждая из них. Для каждой транзакции необходимое выяснить следующее.
Отношения и атрибуты, к которым осуществляется доступ в процессе выполнения транзакции, а также тип доступа; это означает определение того, выполняется ли в этой транзакции вставка, обновление, удаление или выборка данных.
При изучении транзакции обновления необходимо определить, какие атрибуты обновляются в данной транзакции, поскольку эти атрибуты могут потребовать применения вспомогательных структур доступа.
Атрибуты, которые используются в любых предикатах (в языке SQL предикатами являются условия, указанные в конструкции WHERE). Проверка того, предусматривают ли эти предикаты следующее:
сопоставление с шаблоном, например name LIKE '%Smith%';
поиск в диапазоне, например salary BETWEEN 10000 AND 20000;
выборка по точному значению ключа, например salary = 30000.
Следует учитывать, что такие атрибуты могут потребовать создания вспомогательных структур доступа.