Физическое проектирование БД

Противоречия теории и практики нормализации

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

Пример:

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

Физическое проектирование БД

Денормализация для оптимизации

Если еще раз внимательно посмотреть на шаги процесса построения «хорошей» нормализованной схемы реляционной базы данных, то можно заметить, что на

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

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

Физическое проектирование БД

Денормализация для оптимизации

Если еще раз внимательно посмотреть на шаги процесса построения «хорошей» нормализованной схемы реляционной базы данных, то можно заметить, что на

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

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

Физическое проектирование БД

Оптимизация запросов

Оптимизация запросов к БД связана с построением адекватной запросам и

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

Оптимальная структура индексов

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

Физическое проектирование БД

Оптимизация запросов

«Полезность» индекса

Эффективность использования индекса при поиске информации в таблице БД сильно зависит от того, построен ли индекс по уникальным значениям и, если нет, насколько отличаются данные, по которым он построен.

Рассмотрим пример возможного логического порядка использования индексов при выполнении запроса для некоторого сервера БД (в общем случае для конкретного сервера БД реальный порядок выполнения запроса может быть другим).

Пусть необходимо выбрать из таблицы из таблицы RASHOD все записи о расходе товара за 10.10.2006, у которых количество расходуемого товара превышает 300 единиц.

SELECT *

FROM RASHOD

WHERE DAT_RASH = “10.10.2007” AND

KOLVO > 300

Физическое проектирование БД

Оптимизация запросов

«Полезность» индекса

SELECT *

FROM RASHOD

WHERE DAT_RASH = “10.10.2007” AND

KOLVO > 300

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

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

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

Физическое проектирование БД

Оптимизация запросов

Целесообразность создания индексов

Индексы необходимо создавать в случае, когда по столбцу или группе столбцов:

•Часто производится поиск в БД;

•Часто строятся соединения таблиц;

•Часто производится сортировка;

Не рекомендуется строить индексы по столбцам или группам столбцов, которые:

•Редко используются для поиска, объединения , сортировки результатов запроса

•Часто меняют значение, что приводит к необходимости часто обновлять индекс и способно существенно замедлить скорость работы с БД;

•Содержит небольшое число вариантов значения.

Физическое проектирование БД

Оптимизация запросов

Частичное использование составного индекса

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

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

•Порядок следования условий по столбцам в предложении WHERE оператора SELECT не важен (если условия объединяются по AND).

Физическое проектирование БД

Оптимизация запросов

Уменьшение общего количества индексов.

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

1.индексы фактически использующиеся запросами для доступа к данным

2.индексы, внесенные в БД для обеспечения ссылочной целостности.

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