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

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

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

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

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

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

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

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

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

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

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

SELECT *

FROM RASHOD

WHERE DAT_RASH = “10.10.2007” AND

KOLVO > 300

При выполнении запроса сервер БД определяет – есть ли индексы, построенные одновременно по столбцам DAT_RASH и KOLVO, столбцам KOLVO и DAT_RASH? Или индексы, в которые указанные столбцы входят в качестве ведущих.(например, индекс, построенный по столбцам DAT_RASH, KOLVO,TOVAR, но не индекс, построенный по столбцам DAT_RASH, TOVAR, KOLVO). При отсутствии таких индексов проверяется наличие индексов отдельно по столбцам DAT_RASH и KOLVO .

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

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

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