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

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

• выбирается атрибут, наиболее часто применяемый в операциях соединения, поскольку именно он позволяет повысить эффективность таких операций;

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

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

Выбор дополнительных индексов

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

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

• Ввод индексной записи в каждый дополнительный индекс при вставке строки в отношение.

• Обновление дополнительного индекса при обновлении соответствующей строки в отношении.

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

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

Рекомендации по выбору списка требований к индексам

1. Не создавать индекс на небольших отношениях.

2. Как правило, следует создавать индекс на первичном ключе отношения, если он не применяется в качестве ключа файловой структуры.

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

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

5. Ввести дополнительные индексы на атрибутах, которые часто применяются в следующих конструкциях: критерии выборки или соединения, конструкции ORDER BY, конструкции GROUP BY; другие операции, требующие сортировки (такие как UNION и DISTINCT).

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

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

8. Не индексировать атрибут или отношение, которые часто обновляются.

9. Не индексировать атрибут, если в запросах с использованием этого атрибута обычно происходит выборка значительной части (например, 25%) строк кортежей в отношении.

10. Не индексировать атрибуты, которые состоят из длинных символьных строк.

Оценка потребности в дисковом пространстве

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

Проектирование пользовательских представлений

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

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

Проектирование средств защиты

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

• защита системы;

• защита данных.

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