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

Соединения без первичных ключей

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

Риь 7.14. Соединение вида многие ко многим

Этот случай встречается намного чаще, чем предьщущие примеры необычных диаграмм соединений. Хотя в нем есть все те же возможные источники проблем (и решения), как и в случае нескольких корневых узлов, подавляющее большинство соединений вида многие ко многим появляется просто из-за отсутствующих условий соединения. Начните с проверки, не нужно ли условия фильтрации в запросе считать частью соединения, потому что они завершают спецификацию полного первичного ключа для одной из сторон соединения. Пример 5.2 в главе 5 - это такой случай, в котором условие ОТ. Code Type - ORDER STATUS требуется для завершения уникального соединения с псевдонимом ОТ. Если бы я рассматривал это условие как простое фильтрующее условие для псевдонима ОТ, то соединение с ОТ превратилось бы в соединение вида многие ко многим . Даже если вы не находите отсутствующую часть соединения среди фильтрующих условий запроса, всегда следует подозревать, что она по ошибке не была указана в запросе.

Такой случай отсутствующего условия соединения особенно часто встречается, когда дизайн базы данных разрешает существование нескольких типов сущностей или разбиений в пределах таблицы, а разработчик забывает ограничить разбиение или тип в запросе. Например, в предыдущем примере с таблицей Code Trans1 ati ons для каждого Code Type существовали различные типы сущностей преобразования (translation), и если бы условие для Code Type не было указано, то соединение с Code Translat1ons превратилось бы в соединение вида многие ко многим . Зачас-

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

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

Соединения вида один к одному

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

Соединение вида один к одному с таблицей-подмножеством

На рис. 7.15 показано типичное соединение вида один к одному , встроенное в большой запрос. В то время как у соединения вида многие ко многим на обоих концах детальные коэффициенты соединения, у соединения вида один к одному это главные коэффициенты соединения. Главные коэффициенты соединения в этом примере показывают, что соединение между Т1 и Т2 в действительности бывает только один к нулю или один к одному ; случай один к нулю возникает для 30 % строк из Т1.

Рис. 7.15. Типичное соединение вида один к одному

Так как это внутреннее соединение, случаи соединения один к нулю между Т1 и Т2 представляют собой скрытый фильтр соединения, который следует обрабатывать, как описано в конце главы 6. Также обратите внимание, что это может быть случай скрытого ци101ического соединения, что часто случается, когда главная таблица однозначно ( один к одному ) соединяется с другой таблицей. Если над Т1 есть детальная таблица, что подразумевается окрашенной в серый цвет связью вверх, и если эта детальная таблица соединяется с Т1 по тому же уникальному ключу, что и с Т2, то по закону транзитивности у вас есть подразумеваемое соединение от детальной таблицы к 12. На рис. 7.16 подразумеваемая связь показана серым. О том, как обрабатывать циклические соединения, рассказывалось несколько раньше в этой главе.

Рис 7.16. Подразумеваемая связь, создающая циклическое соединение

Есть у вас циклическое соединение или нет, вы всегда можете улучшить дизайн базы данных. Случай на рис. 7.16 подразумевает набор сущностей, однозначно отображающихся на Т1, и поднабор тех же сущностей, однозначно отображающихся на 12, причем таблица 12 построена из первичного ключа Т1 и столбцов, которые употребляются только для этого поднабора. В этом случае совершенно нет жесткой необходимости в двух таблицах. Попробуйте просто добавить дополнительные столбцы к Т1 и присвоить им значение null для членов большого набора, которые не входят в поднабор. Иногда есть и другие причины, почему для удобства в подобных ситуациях разработчик предпочитает иметь две таблицы. Однако с точки зрения настройки комбинирование этих соразмерных таблиц практически всегда полезно, поэтому хотя бы подумайте об их использовании, если у вас есть возможность влиять на дизайн базы данных.

Точные соединения один к одному

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

Рис. 7.17. Точное соединение вида один к одному