Encyclopedia

Join dependency

Database constraint

Wikipedia contributorsAdapted for Fathomly · View authors

2 min read
Source updated December 22, 2025

In database theory, a join dependency is a constraint on the set of legal relations over a database scheme. A table $T$ is subject to a join dependency if $T$ can always be recreated by joining multiple tables each having a subset of the attributes of $T$ . If one of the tables in the join has all the attributes of the table $T$ , the join dependency is called trivial.

The join dependency plays an important role in the fifth normal form (5NF), also known as project-join normal form, because it can be proven that if a scheme $R$ is decomposed in tables $R_{1}$ to $R_{n}$ , the decomposition will be a lossless-join decomposition if the legal relations on $R$ are restricted to a join dependency on $R$ called $*(R_{1},R_{2},\ldots ,R_{n})$ .

Another way to describe a join dependency is to say that the relations in the join dependency are independent of each other.

Unlike in the case of functional dependencies, there is no sound and complete axiomatization for join dependencies, though axiomatization exist for more expressive dependency languages such as full typed dependencies. However, implication of join dependencies is decidable.

01Formal definition

Let $R$ be a relation schema and let $R_{1},R_{2},\ldots ,R_{n}$ be a decomposition of $R$ .

The relation $r(R)$ satisfies the join dependency

$*(R_{1},R_{2},\ldots ,R_{n})$ if $\bowtie _{i=1}^{n}\Pi _{R_{i}}(r)=r.$

A join dependency is trivial if one of the $R_{i}$ is $R$ itself.

2-ary join dependencies are called multivalued dependency as a historical artifact of the fact that they were studied before the general case. More specifically if U is a set of attributes and R a relation over it, then R satisfies $X\twoheadrightarrow Y$ if and only if R satisfies $*(X\cup Y,X\cup (U-Y)).$

02Example

Given a pizza-chain that models purchases in table Order = {order-number, customer-name, pizza-name, courier}. The following relations can be derived:

customer-name depends on order-number
pizza-name depends on order-number
courier depends on order-number

Since the relationships are independent there is a join dependency as follows: *((order-number, customer-name), (order-number, pizza-name), (order-number, courier)).

If each customer has his own courier however, there can be a join-dependency like this: *((order-number, customer-name), (order-number, pizza-name), (order-number, courier), (customer-name, courier)), but *((order-number, customer-name, courier), (order-number, pizza-name)) would be valid as well. This makes it obvious that just having a join dependency is not enough to normalize a database scheme.

Watch videos about Join dependencyExplainers and documentaries on YouTube (opens in a new tab)

Sources and credits

This article is adapted from the Wikipedia article “Join dependency”, written by its contributors and licensed under CC BY-SA 4.0. Fathomly has changed the layout, removed citation markers, navigation and maintenance notices, and adjusted punctuation. This adapted version is shared under the same license. For references, see the original article.

Fathomly is not affiliated with or endorsed by the Wikimedia Foundation. Spotted a problem? Tell us.

Join dependency

01Formal definition

02Example

Sources and credits

Related topics

Chase (algorithm)

Universal relation assumption