Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Тоу Д. -> "Настройка SQL. Для профессионалов" -> 77

Настройка SQL. Для профессионалов - Тоу Д.

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 71 72 73 74 75 76 < 77 > 78 79 80 81 82 83 .. 161 >> Следующая


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

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

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

ПРИМЕЧАНИЕ--------------------------------------------------------------------------

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

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

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

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

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

151

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

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

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

¦ Вопрос, на который отвечает запрос, — это обычно вопрос о сущности, представленной в корневом узле дерева (или об агрегациях этой сущности).

¦ Прочие таблицы просто предоставляют справочные и детализированные данные, хранящиеся в них для нормализации.

Упрощенные диаграммы запросов

Вы увидите, что множество подробностей, присутствующих на полных диаграммах запросов, не обязательны, разве что для самых редких проблем. Когда вы концентрируетесь на необходимых элементах, то вам нужен только скелет диаграммы и приблизительные коэффициенты фильтрации. Изредка требуются коэффициенты соединений, но обычно только когда любой из детальных коэффициентов соединения меньше 1,5 или главный коэффициент соединения меньше 0,9. Если только у вас нет причины подозревать, что вы встретились именно с этими редкими значениями для отношения главной и детальной таблиц, можете даже не беспокоиться о вычислении этих значений. Это, в свою очередь, значит, что меньшее количество данных требует создания более простых диаграмм соединения. Вам не потребуется узнавать количество строк для таблиц без фильтров. На практике в многосторонних соединениях обычно есть фильтры только для 3-5 таблиц, поэтому даже самый сложный запрос легко изобразить на диаграмме, не используя множество запросов для сбора статистики.

Отбросив ненужные детали, которые я только что перечислил, вы можете упростить рис. 5.5 до рис. 5.7.

OD

Рис. 5.7. Упрощенная диаграмма запроса для рис. 5.5

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

5. Диаграммное изображение простых запросов SQL

Когда дело доходит до фильтров, даже приблизительные значения обычно не нужны, если вы знаете, какой фильтр лучше и если другие конкурирующие фильтры не относятся к тому же родительскому детальному узлу. В нашем случае можно обозначить наилучший фильтр заглавной буквой F и малые фильтры — строчной буквой f. Рисунок 5.7 упрощается до рис. 5.8.

OD

S P Of ODT

А CF ОТ

Рис. S.8. Полностью упрощенная диаграмма запроса для рис. 5.7

Обратите внимание, что детальный коэффициент соединения от С к О меньше 1,5, поэтому я продолжаю указывать его даже на полностью упрощенной диаграмме на рис. 5.8.
Предыдущая << 1 .. 71 72 73 74 75 76 < 77 > 78 79 80 81 82 83 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100