7.3.4. Анализ необходимости введения контролируемой избыточности.

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

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

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

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

• Объединение членов связей типа "один-к-одному" (1:1).

• Дублирование неключевых атрибутов в связях типа "один-ко-многим" (1:М) с целью сокращения числа выполняемых соединений отношений.

• Использование справочных таблиц.

• Дублирование атрибутов внешних ключей в связях типа "один-ко-многим" (1:М) с целью сокращения числа выполняемых соединений отношений.

• Дублирование атрибутов связей типа "многие-ко-многим" (M:N) с целью сокращения числа выполняемых соединений отношений.

• Введение повторяющихся групп атрибутов.

• Создание сводных таблиц.

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

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

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

Мы проиллюстрируем процесс определения объема дискового пространства на примере файлов с организацией, обсуждавшейся на этапе 7.3.2. В качестве целевой будет использована СУБД INGRES. Все формулы рассчитаны для вновь созданных и заполненных данными таблиц, до того как данные в них обновлялись или удалялись. В общем случае вычисление объема дисковой памяти, необходимого для размещения некоторой таблицы, предусматривает умножение количества записей в таблице на размер этой записи, после чего к результату добавляются объемы всех требуемых индексов. Длина записи определяется как сумма длин атрибутов плюс суммарная длина любых дополнительных элементов, помещаемых в запись системой. Длина атрибута в определенной степени задается его типом и размером. В СУБД INGRES длина записи вычисляется как общая длина всех атрибутов в байтах, плюс два дополнительных байта на каждый символьный атрибут с переменной длиной строки и еще по одному байту для полей, которые могут хранить значение NULL.