Normally we think of normalization applying to entity tables, not intersection tables. That is because a bare intersection table contains only independent keys, not attributes. In general, keys are created during the normalization process, so all dependencies are already resolved (assuming proper design).
However, an intersection table defines a relationship and relationships can have additional attributes.
create table DeptMgrs(
DeptID int not null references Departments( ID ),
MgrID int not null references Employees( ID ),
Assigned date not null,
constraint PK_DeptMgrs primary key( DeptID, MgrID )
);
Normally, there are no functional dependencies between the FK fields of an intersection table, thus none between DeptID
and MgrID
-- they are imported key fields and together they form the natural key of the relationship. However, the Assigned field tells the date this employee became the manager of that department. It is an attribute not of a department or an employee but of the relationship between them. Of course, this example is trivially in 3nf and even BCNF, but with additional attributes, normalization of the intersection table just may be required.
And shouldn't that be loads of fun?
Since you appear to have only FK fields in your intersection table, there should be no dependencies between them.