Этап 4.2. Разработка способов получения производных данных

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

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

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

• затраты на вычисление производных данных, если их вычисление выполняется по мере необходимости.

Из этих двух вариантов выбирается наименее дорогостоящий с учетом требований к производительности.

Документальное оформление проекта получения производных данных

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

Этап 4.3. Реализация ограничений предметной области

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

Документальное оформление проекта реализации ограничений предметной области

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

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

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

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

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

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

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

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

Определение понятия системных ресурсов

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

• Оперативная память. Доступ к данным в оперативной памяти осуществляется намного (в десятки или даже в сотни и тысячи раз) быстрее, чем к данным во внешней памяти. В общем случае, чем больший объем оперативной памяти доступен для СУБД и приложений базы данных, тем быстрее выполняются приложения. Опыт показывает, что полезно постоянно поддерживать в системе такой режим, при котором около 5% ее оперативной памяти остается свободной. Однако неразумно поддерживать уровень свободной памяти выше 10%, поскольку в этом случае оперативная память будет использоваться неэффективно. Если в системе не хватает оперативной памяти для удовлетворения потребностей всех процессов, операционная система освобождает часть этой памяти, передавая отдельные страницы памяти некоторых процессов на диск. Эти страницы будут считаны с диска, как только вновь потребуется доступ к содержащимся в них данным. Такая операция называется свопингом, или страничным обменом. В определенных случаях для получения необходимого объема свободной памяти системе приходится перемещать на диск все страницы памяти, отведенные целому процессу, а затем возвращать их обратно. Но если интенсивность свопинга (страничного обмена) становится слишком высокой, это указывает на нехватку оперативной памяти в системе.

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

• Дисковый ввод-вывод. В любой достаточно мощной СУБД процессы сохранения и выборки данных связаны с выполнением множества дисковых операций ввода-вывода. Как правило, изготовители дисковых устройств указывают рекомендуемое количество операций ввода-вывода в секунду. Если реальный показатель превышает данное значение, дисковая подсистема превращается в узкое место системы. На общую производительность дисковой памяти очень большое влияние оказывает способ организации хранения данных. Рекомендуется равномерно распределять хранимые данные между всеми доступными в системе устройствами, что снижает вероятность появления проблем. Можно указать следующие достаточно общие принципы распределения данных по дисковым устройствам.

• Файлы операционной системы должны быть отделены от файлов базы

данных.

• Основные файлы базы данных должны быть отделены от индексных файлов.

• Журнал восстановления должен быть отделен от остальной части базы данных.

• Сеть. Сеть может стать узким местом всей системы при чрезмерном возрастании сетевого трафика или большом количестве сетевых коллизий.

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

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

1. Анализ транзакций.

2. Выбор файловой структуры.

3. Определение индексов.

4. Определение требований к дисковой памяти.