Подходы к проектированию баз данных

Этап 5.2.5. Документирование результатов выбора структуры файлов таблиц

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

Этап 5.3. Определение вторичных индексов

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

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

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

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

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

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

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

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

Этап 5.4.1. Анализ целесообразности использования производных  данных

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

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

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

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

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

Этап 5.4.2. Анализ целесообразности дублирования атрибутов  или объединения отношений

Объединение членов связей типа "один к одному" (1:1). Объединять имеет смысл только такие пары отношений, которые часто используются совместно и значительно реже — по отдельности.

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

Следует сравнить выигрыш, достигаемый  от этого изменения, с теми осложнениями, которые могут возникнуть в их результате. Например, если продублированные данные будут изменены в родительском отношении, то они одновременно должны быть изменены и в дочернем отношении. Более того, поскольку связь имеет  тип 1:М, в дочернем отношении возможно наличие нескольких строк с одним и тем же значением. Таким образом, потребуется поддерживать согласованность сразу нескольких копий атрибута. Если процедуру обновления атрибута не удастся автоматизировать, то появится потенциальная возможность потери целостности данных в базе. Еще одна проблема, связанная с дублированием атрибутов, заключается в дополнительном времени, затрачиваемом на выполнение процедур автоматической поддержки согласованности данных при каждой вставке, обновлении или удалении строки в родительском отношении.

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

Использование справочных таблиц. Справочные таблицы, иногда называемые ссылочными таблицами (или списками значений), являются особым случаем связей типа 1:М. Как правило, в типичной справочной таблице содержатся атрибуты кода или шифра и описания.

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

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

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

Введение повторяющихся  групп атрибутов. Повторяющиеся группы атрибутов были удалены из логической модели данных при приведении всех сущностей к представлению в первой нормальной форме. Повторяющиеся группы были выделены в отдельные отношения, образующие с исходным (родительским) отношением связь типа 1:М. Тем не менее повторное введение в отношения групп повторяющихся атрибутов является эффективным способом повышения производительности системы.

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

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

Этап 5.4.3. Документирование результатов введения избыточности

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

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

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

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

Этап 6. Разработка механизмов защиты

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

Этап 6.1. Разработка пользовательских представлений (видов)

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

Как правило, представления  создаются с помощью операторов языка SQL.

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

Этап 6.2. Определение прав доступа

Один из способов организации  защиты состоит в использовании  средств ограничения доступа, предоставляемых  языком SQL. Как правило, рядовым пользователям прямой доступ к таблицам базы данных никогда не предоставляется. Они работают с этими таблицами через представления (виды), созданные на этапе 6.1. Подобный подход обеспечивает высокую степень независимости от данных и изолирует и пользователей от возможных изменений в структуре базы данных.

Привилегиями (или правами  доступа) называются действия, которые  пользователю разрешено выполнять  в отношении конкретной таблицы  или представления.

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

Разработанная схема представлений  пользователей и связанный с  ними механизм защиты должны быть тщательно  описаны в документации.

 

Этап 7. Организация мониторинга и настройка  функционирования системы

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

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

• Устранить необходимость приобретения дополнительного оборудования.

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