Соединения, объясненные диаграммой Венна с более чем одним соединением

http://www.codinghorror.com/blog/2007/10/a-visual-explanation-of-sql-joins.html и http://www.khankennels.com/blog/index.php/archives/2007/04/20/getting-joins/

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

Допустим, у меня есть 3 таблицы:

Сотрудники

EmployeeID
FullName
EmployeeTypeID

Типы сотрудников (полный рабочий день, неполный рабочий день и т. д.)

EmployeeTypeID
TypeName

Страховые отчеты

InsuranceRecordID
EmployeeID
HealthInsuranceNumber

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

EmployeeID | FullName | TypeName | HealthInsuranceNumber

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

SELECT 
    Employees.EmployeeID, FullName, TypeName, HealthInsuranceNumber 
FROM Employees
INNER JOIN EmployeeTypes ON Employees.EmployeeTypeID = EmployeeTypes.EmployeeTypeID
LEFT OUTER JOIN InsuranceRecords ON Employees.EmployeeID = InsuranceRecords.EmployeeID

Мой вопрос заключается в том, что, используя тот же шаблон диаграммы Венна, как будет визуально представлен приведенный выше запрос? Эта картина точна?

несколько объединений


sql sql-server join data-visualization venn-diagram
person CptSupermrkt    schedule 30.07.2012    source источник
comment
Чтобы не быть придирчивым, но это диаграмма Эйлера, а не диаграмма Венна.   -  person Jesse    schedule 30.07.2012

Ответы (2)


arrow_upward
3
arrow_downward

Я думаю, что не совсем возможно сопоставить ваш пример с этими типами диаграмм по следующей причине:

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

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

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

Надеюсь это поможет.

person Cornelius    schedule 30.07.2012

arrow_upward
0
arrow_downward

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

Пример Джеффа в блоге Coding Horror работает только с похожими сущностями, то есть с двумя таблицами, содержащими одни и те же сущности — технически нарушение нормализации — или самосоединение.

Диаграммы Венна могут точно отображать такие сценарии, как:

-- The intersection lens
SELECT *
FROM table
WHERE condition1
    AND condition2

-- One of the lunes
SELECT *
FROM table
WHERE condition1
    AND NOT condition2

-- The union
SELECT *
FROM table
WHERE condition1
    OR condition2
person Cade Roux    schedule 04.08.2012