Let me summarize where we are. The general point is that some JDs imply others. As specific illustrations of this point, we’ve discussed:
Irrelevant components: Every JD J is equivalent to a JD J′ that’s obtained from J by adding or dropping irrelevant components.
Combining components: Every JD J implies a JD J′ that’s obtained from J by replacing two components by their union.
Irreducibility: Every JD J that holds in relvar R is equivalent to at least one JD J′—not necessarily distinct from J—that holds in R and is irreducible (where equivalent and irreducible must both be understood as being with respect to R). It follows that R’s irreducible JDs in fact imply all of R’s JDs.
The following observations are also valid (I haven’t discussed them in detail, but they’re intuitively obvious):
Adding attributes: If JD J holds in relvar R, then so does every JD J′ that’s obtained from J by adding some attribute of R to some component of J.
Adding components: If JD J holds in relvar R, then so does every JD J′ that’s obtained from J by adding any subset of the heading of R as another component.
Observe in both of these cases, however, that we’re talking about implication, not equivalence. For example, in relvar S (but ignoring SNAME once again, for simplicity), the JD 
{SNO,STATUS},{SNO,CITY}} holds, and therefore the following JD holds too: {{SNO,STATUS},{SNO,CITY},{CITY,STATUS}}. However, the converse is false—if the latter JD holds, it doesn’t follow that the former one does.[107]
We can also say the following: If J is a JD that holds in relvar R and J implies another JD J′, where J′ is obtained from J by dropping attributes from components of J and/or dropping entire components from J, then J is certainly a “bad” JD (see the remarks on the topic of good vs. bad JDs at the end of the section COMBINING COMPONENTS). However, not all “bad” JDs can be obtained in this simple fashion, as we’ll see.
Now I’d like to generalize the discussion somewhat. First of all, from this point forward I’ll take the term dependencies to mean either FDs or JDs or both, as the context demands.[108] Now, throughout this book so far, whenever I’ve considered the question of dependencies being implied by others, I’ve tacitly limited my attention to ones that are implied by an individual dependency. More generally, however, it turns out that certain sets of dependencies can imply others. Let me give an example.
Consider a relvar SPT, with attributes SNO, PNO, and STATUS (only), where the attributes have their usual meanings. Suppose we’re told, not unreasonably, that the following dependencies (one FD and one JD) both hold in this relvar:
{ SNO , PNO } → { STATUS }
{ { SNO , PNO } , { SNO , STATUS } }Now, given the semantics of the situation, it’s intuitively obvious that (a) {SNO} isn’t a key for SPT and yet (b) the FD {SNO} → {STATUS} holds in SPT implicitly (and so SPT isn’t in 2NF, incidentally). Note that I say “implicitly” because we haven’t been told the FD holds explicitly. The question is: Can we prove (a) and (b), given only that the stated FD and JD hold? That is, can we show that (a) and (b) are valid formally, without paying any regard to semantics? (After all, that’s what the system would have to do, if we wanted it to be able to infer dependencies. The system doesn’t know anything about semantics, as I’m using that term here.)[109]
So let’s give it a try. First of all, suppose the following tuples appear in SPT:
s1 p1 t2s1 p2 t1
Suppose also that p1 ≠ p2. Now what we need to do, in order to show the FD {SNO} → {STATUS} holds, is to show that t1 and t2 must necessarily be equal. We begin by writing down the projections of these two tuples corresponding to the components of the given JD {{SNO,PNO},{SNO,STATUS}}:
s1 p1 s1 t2s1 p2 s1 t1
Joining these projections together, we obtain the original two tuples plus two extra ones (shown below in bold):
s1 p1 t2s1 p1 t1s1 p2 t2s1 p2 t1
Since the given JD holds, the two extra tuples must in fact appear in the relvar along with the original two. But the FD {SNO,PNO} → {STATUS} holds also; it follows that t1 = t2, and hence that the FD {SNO} → {STATUS} holds (every tuple that has SNO s1 also has STATUS t1). This is part (b) of what was to be proved. At the same time, by our assumption we have p1 ≠ p2—note that nothing in the argument so far invalidates that assumption—from which it follows that the FD {SNO} → {PNO} doesn’t hold, and so {SNO} isn’t a key; and this is part (a) of what was to be proved.
So we see that any given relvar is subject to both explicit dependencies (these are the ones explicitly declared) and implicit dependencies (these are the ones implied by the explicitly declared ones). For the record, let me bring these points together into an appropriate definition:
Definition: Let R be a relvar. Associated with R are two sets of explicit dependencies: a set XFD of explicit FDs that hold in R and a set XJD of explicit JDs that hold in R. The FDs in XFD together with the JDs in XJD are the explicit dependencies of R. The FDs and JDs that aren’t in XFD or XJD but are logical consequences of the ones in XFD and XJD are the implicit dependencies of R. The explicit and implicit dependencies of R taken together are the dependencies of R. A relation r can be assigned to R only if that relation r satisfies all of the dependencies of R.
[107] Of course, the former JD does hold in our running example, thanks to the fact that the FD {CITY} → {STATUS} also holds. But the latter JD doesn’t imply the former in general.
[108] As we know, other kinds of dependencies—e.g., equality dependencies, which were mentioned in passing in Chapter 3 and elsewhere and are discussed further in Chapter 13—exist also, but I'm deliberately excluding them from consideration at this time.
[109] I note in passing that a proof of part (b) follows immediately from what Exercise 11.3, q.v., refers to as the converse of an extended version of Heath’s theorem.