Now I’d like to extend Example 4 slightly in order to make an additional point. Suppose relvar EMP does include at least one additional attribute, JOB; suppose further that a given employee is a programmer, and is represented in relvar PGMR, if and only if the JOB value in that employee’s tuple in EMP has the value “Programmer” (perhaps other values of JOB—“Janitor”, for example—correspond to other relvars). This kind of situation is not at all uncommon in practice, by the way. Now there’s definitely some redundancy, because the design is subject to the following equality dependency (as well as many similar ones, possibly):

     CONSTRAINT ...
        ( EMP WHERE JOB = 'Programmer' ) { ENO } = PGMR { ENO } ;

Note, however, that there’s no violation of orthogonality in this example, even if all employees, programmers included, are represented in EMP. Suppose they are; then it’s clearly the case that the projection of PGMR on {ENO} is equal to a certain subset—it’s not a restriction as such—of the projection of EMP on {ENO}. (Exercise: Why isn’t it a restriction as such?) But neither of those projections corresponds to a component of any irreducible JD that holds in the pertinent relvar.^[158] (Check the final version of The Principle of Orthogonal Design in Chapter 14 if you need to refresh your memory on this point.) Thus, a database can be fully orthogonal and yet still exhibit some redundancy.