SQL Joins as Venn Diagram

sql joins as venn diagram

I think your main underlying confusion is that when (for example) only A is highlighted in red, you're taking that to mean "the query only returns data from A", but in fact it means "the query only returns data for those cases where A has a record". The query might still contain data from B. (For cases where B does not have a record, the query will substitute NULL.)

Similarly, the image below that only includes data from the B circle, so why is A included at all in the join statement?

If you mean — the image where A is entirely in white, and there's a red crescent-shape for the part of B that doesn't overlap with A, then: the reason that A appears in the query is, A is how it finds the records in B that need to be excluded. (If A didn't appear in the query, then Venn diagram wouldn't have A, it would only show B, and there'd be no way to distinguish the desired records from the unwanted ones.)

The image makes it seem like circle B is the primary focus of the sql statement, but the sql statement itself, by starting with A (select from A, join B), conveys the opposite impression to me, namely that A would be the focus of the sql statement.

Quite right. For this reason, RIGHT JOINs are relatively uncommon; although a query that uses a LEFT JOIN can nearly always be re-ordered to use a RIGHT JOIN instead (and vice versa), usually people will write their queries with LEFT JOIN and not with RIGHT JOIN.

Joins explained by Venn Diagram with more than one join

I think it is not quite possible to map your example onto these types of diagrams for the following reason:

The diagrams here are diagrams used to describe intersections and unions in set theory. For the purpose of having an overlap as depicted in the diagrams, all three diagrams need to contain elements of the same type which by definition is not possible if we are dealing with three different tables where each contains a different type of (row-)object.

If all three tables would be joined on the same key then you could identify the values of this key as the elements the sets contain but since this is not the case in your example these kind of pictures are not applicable.

If we do assume that in your example both joins use the same key, then only the green area would be the correct result since the first join restricts you to the intersection of Employees and Employee types and the second join restricts you the all of Employees and since both join conditions must be true you would get the intersection of both of the aforementioned sections which is the green area.

Hope this helps.

Venn Diagram for Natural Join

Venn diagrams are not very helpful for understanding natural join or inner join. Most Venn diagrams associated with joins on Stack Overflow are parroted worthless misrepresentations--even in cases where a Venn diagram could be useful.

Here are some valid uses of Venn diagrams for SQL natural join:

If you ignore column order, we can have an area be a set whose elements are an associated table's column names. Then the left & right circles' elements are the left & right tables' column names & the combined elements are the result's column names.

If input table columns with the same name have the same type then we can have an area be the set whose elements are the subrow values that appear somewhere in a table for the common columns. Then the left & right circles' elements are the left & right tables' such subrow values & the intersection elements are the result's such subrow values.

But neither diagram nor the pair tells us what the output rows are.

From my answer at CROSS JOIN vs INNER JOIN in SQL Server 2008:

Re Venn diagrams A Venn diagram with two intersecting circles can illustrate the difference between output rows for INNER, LEFT, RIGHT & FULL JOINs for the same input. And when the ON is unconditionally TRUE, the INNER JOIN result is the same as CROSS JOIN. Also it can illustrate the input & output rows for INTERSECT, UNION & EXCEPT. And when both inputs have the same columns, the INTERSECT result is the same as for standard SQL NATURAL JOIN, and the EXCEPT result is the same as for certain idioms involving LEFT & RIGHT JOIN. But it does not illustrate how (INNER) JOIN works in general. That just seems plausible at first glance. It can identify parts of input and/or output for special cases of ON, PKs (primary keys), FKs (foreign keys) and/or SELECT. All you have to do to see this is to identify what exactly are the elements of the sets represented by the circles. (Which muddled presentations never make clear.) (Remember that in general for joins output rows have different headings from input rows.)

I repeat with emphasis:

But it does not illustrate how (INNER) JOIN works in general.

All you have to do to see this is to identify what exactly are the elements of the sets represented by the circles.

From my comments (using "key" in the sense of "legend") on an answer re its Venn diagram "Figure 1" for inner join:

Figure 1 is a common terrible attempt to explain JOIN. Its key is also complex: It's only for tables as sets & only equijoin & only one [column]; it also represents the input differently than the output. Write it for JOIN in general.

From my comments on What is the difference between “INNER JOIN” and “OUTER JOIN”?:

Venn diagrams show elements in sets. Just try to identify exactly what the sets are and what the elements are in these diagrams. The sets aren't the tables and the elements aren't their rows. Also any two tables can be joined, so PKs & FKs are irrelvant. All bogus. You are doing just what thousands of others have done--got a vague impression you (wrongly) assume makes sense.

Of the answers & comments & their references below only one actually explains how Venn diagrams represent the operators: The circle intersection area represents the set of rows in A JOIN B. The area unique to each circle represents the set of rows you get by taking its table's rows that don't participate in A JOIN B and adding the columns unique to the other table all set to NULL. (And most give a vague bogus correspondence of the circles to A and B.)

So Venn diagrams are relevant for certain cases where tables can reasonably be considered to hold sets of row-valued elements. But in general SQL tables do not hold sets of row-valued elements, while Venn diagrams denote sets.

Re illustrating inner vs outer joins via Venn diagrams:

From my comment on LEFT JOIN vs. LEFT OUTER JOIN in SQL Server

Re Venn diagrams: If no nulls or duplicate rows are input, so we can take a table to be a set of row-valued values & use normal math =, then the Venn diagrams are OK--taking circles to hold left & right join output tables/sets. But if nulls or duplicate rows are input then it is so difficult to explain just what the circles are sets of & how those sets relate to input & output tables/bags that Venn diagrams are not helpful.

From my comment on my answer at What is the difference between “INNER JOIN” and “OUTER JOIN”?

I must admit that, despite my quick phrasing in comments, because SQL involves bags & nulls and SQL culture doesn't have common terminology to name & distinguish between relevant notions, it is non-trivial even to explain clearly how elements of a Venn diagram are 1:1 with output "rows", let alone input "rows". Or what inner or outer joins do, let alone their difference. "value" may or may not include NULL, "row" may be a list of values vs a slot in a table value or variable & "=" may be SQL "=" vs equality.

PS Often diagrams are called Venn diagrams when they are really Euler diagrams.

SQL JOIN 3 Tables all query combinations

/* 1 */

SELECT A.PK as A_PK, A.Value as A_Value, B.PK as B_PK, B.Value as B_Value, C.PK as C_PK, C.Value as C_Value from table_a A LEFT JOIN table_b B on B.PK=A.PK LEFT JOIN table_c C on C.PK=A.PK where B.PK is NULL and C.PK is NULL;

/* 2 */

SELECT A.PK as A_PK, A.Value as A_Value, B.PK as B_PK, B.Value as B_Value, C.PK as C_PK, C.Value as C_Value from table_b B LEFT JOIN table_a A on B.PK=A.PK LEFT JOIN table_c C on C.PK=B.PK where C.PK is NULL and A.PK is NULL;

/* 3 */

SELECT A.PK as A_PK, A.Value as A_Value, B.PK as B_PK, B.Value as B_Value, C.PK as C_PK, C.Value as C_Value from table_a A INNER JOIN table_b B on A.PK=B.PK LEFT JOIN table_c C on A.PK=C.PK where A.PK=B.PK and C.PK is NULL;

/* 4 */

SELECT A.PK as A_PK, A.Value as A_Value, B.PK as B_PK, B.Value as B_Value, C.PK as C_PK, C.Value as C_Value from table_c C LEFT JOIN table_a A on C.PK=A.PK LEFT JOIN table_b B on C.PK=B.PK where A.PK is NULL and B.PK is NULL;

/* 5 */

SELECT A.PK as A_PK, A.Value as A_Value, B.PK as B_PK, B.Value as B_Value, C.PK as C_PK, C.Value as C_Value from table_a A LEFT JOIN table_b B on A.PK=B.PK INNER JOIN table_c C on A.PK=C.PK where A.PK=C.PK and B.PK is NULL;

/* 6 */

SELECT A.PK as A_PK, A.Value as A_Value, B.PK as B_PK, B.Value as B_Value, C.PK as C_PK, C.Value as C_Value from table_b B LEFT JOIN table_a A on A.PK=B.PK INNER JOIN table_c C on B.PK=C.PK where B.PK=C.PK and A.PK is NULL;

/* 7 */

SELECT A.PK as A_PK, A.Value as A_Value, B.PK as B_PK, B.Value as B_Value, C.PK as C_PK, C.Value as C_Value from table_a A INNER JOIN table_b B on A.PK=B.PK INNER JOIN table_c C on A.PK=C.PK;

Now I wonder if this could be done with keeping the JOIN clause as INNER JOIN and not mixing LEFT or RIGHT JOINS but I don't want to get down voted again for posting a question.

Isn't SQL A left join B, just A?

No, since it's a join, it can produce cardinalities greater than 1 for the rows in A. That is, if there are multiple matching rows from B then a row in A will show up multiple times.

Example:

Table A:

id name
-- -------
1 Alice
2 Malcolm
3 Kelly

Table B:

id_a preferred_food
---- --------------
1 Pizza
2 Burger
2 Steak
2 Menestroni

Then "A left join B" will give you:

id name    id_a preferred_food
-- ------- ---- --------------
1 Alice 1 Pizza
2 Malcolm 2 Burger
2 Malcolm 2 Steak
2 Malcolm 2 Menestroni
3 Kelly null null

In short:

  • All rows from A show up in the left join: even 3 Kelly shows up.
  • Columns from B will show up with nulls when there are no matching rows in B: row 3 Kelly has null in the last two columns.
  • Rows in A may show up multiple times when they have multiple matches in B: row 2 Malcolm shows up three times.


Related Topics



Leave a reply



Submit