A department's instructor-count data is stored in a normalized relation…

Concept

A functional dependency X → Y holds in a relation when every pair of tuples that agree on X also agree on Y - X determines Y. When an attribute's value depends on more than one column together (a composite determinant), representing that data as one row keyed only by PART of the determinant is ambiguous - to keep the data in a single flat relation without losing information, every attribute of that composite determinant must show up somewhere in the schema, for example as separate columns (one per value of the extra determinant). That is exactly what denormalizing (pivoting) does.

Application

Here, the instructor size for a department differs between 2007 and 2008, and different departments can each carry their own size in the same year. So neither dept_name alone nor year alone fixes size - only the pair (dept_name, year) together does. Because of that composite dependency, a single flat 'size' column keyed only by dept_name would be ambiguous (which year's size would it hold?); pivoting the year component out into separate columns (total_inst_2007, total_inst_2008, ...) is how the schema resolves that ambiguity while staying a single relation.

Cross-check

• If year alone determined size, every department would share one value per year, and there would be no reason to key the pivot by department at all.

• If dept_name alone determined size, one size column per department would suffice for all years - a single flat 'size' column, not a separate 2007/2008 pair.

• A dependency running from size to year would mean each instructor-count value could only ever belong to one specific year, which is not a constraint this data needs to satisfy and is not the direction the pivot was built from.

Only dept_name, year → size accounts for both the per-department variation and the per-year columns, which is why this composite dependency is what the pivoted schema is built on.