A join or other type of table connection (intersection, matching, union) can be considered as an extension of the original query on one table. That is, starting from one table, you move on to the related fields of the joined table. SQL allows you to write nested or sequential join statements in a single expression (not to mention subqueries). As a result, in just one query you can build a whole chain of transitions: from one table to another, from another to a third, and so on.

You can imagine each of the tables as vertices of a graph, and the database as a graph as a whole. Edges between vertices can be designated in two ways:

• Constraints as a relationship between the foreign key of one table and the primary key of another table
• Join practices that are defined in queries. The relationship of tables is indicated in the from and join constructs, and their load in the form of conditions is defined in the join criteria.

Let me remind you that the graph in this case will be bidirectional, since the join operation is commutative (A+B == B+A).

Based on this, it is possible to build search and navigation through data at a higher level than the monotonous writing of similar connections between tables. In addition, problems arise that are traditionally inherent in graph models, such as finding the optimal path between two data elements: attributes, tables.