ключа часто равно null или он часто указывает на более не существующие значения первичного ключа, просто игнорируйте его, подразумевая значение 1,0.

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

SELECT COUNTC*) D. ШШ(.<Столбец внешнего ключа>) F FROM <Летальная таблиид>: SELECT COUNTC*) М FROM <Главная таблица>: ~

Пусть первое количество строк, полученное первым запросом, равно D. Второе количество строк, полученное тем же запросом, равно F. Количество строк, полученное вторым запросом, равно М. Тогда главный коэффициент соединения равен F/D, а детальный коэффициент соединения - F М.

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

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

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

Коэффициенты фильтрации имеют самое главное значение, но обычно варьируются в пределах нескольких порядков, и, если разница между коэффициентами фильтрации очень большая, будет достаточно, если вы угадаете порядок их величины. Для успешной настройки с любыми коэффициентами вам практически никогда не потребуется точность большая, чем до первой отличной от нуля цифры (первой значащей цифры, если вы помните термины из математики старших классов). Например, 0,043 округляется до 0,04 с одной значащей цифрой, а 472 до 500.

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

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

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

Интерпретация диаграмм запросов

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

Employees (Е)

Многие к одному

Один ко многим

Departments (D)

Рис. 5.6. Скелет запроса по сравнению с диаграммой отношений между сущностями

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

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

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

ПРИМЕЧАНИЕ-

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

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

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

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

Например, запрос, соединяющий Employees и Departments - это на самом деле вопрос о сотрудниках, для ответа на который база данных должна обратиться к таблице Departments и получить информацию о сотрудниках, например, Department Name, которую вы храните в таблице Departments для правильной нормализации.

ПРИМЕЧАНИЕ-

Да, я знаю, что для разработчика базы данных Departiiient Name - это свойство отдела, а не сотрудника, но я говорю о вопросе бизнеса, а не формальной базе данных. В нормальной деловой семантике вы думаете о названии отдела (и других свойствах Departments) как о свойстве сотрудников, наследуемом из Departments.

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

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

Запросу соответствует одно дерево.

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