Given the example of the article I tend to avoid building foreign keys to bridge-tables, but rather build a 3-way bridge for the training:

Table Name: Employee_FunctionalArea_TrainingCourse

Column NameData Type

ID int (auto-increment, Primary Key)

FK_Employee int (relates to the Employee Table)

FK_FunctionalArea int (relates to the FunctionalArea Table)

FK_TrainingCourse int (relates to the TrainingCourse table)

TrainingDate DateTime

Then with business-logic I avoid "illogical" permutations (having an Employee do a training for an unrelated functional area).

This can give various answers while avoiding "going through" unnecessary tables (list all courses a certain employee is scheduled for regardless of functional area).

Another benefit is that this bridge-table is not reliant on the Employee_FunctionalArea bridge-table (an employee may at some point no longer be associated with a functional area, but you may still want to see which courses this employee has completed in the past related to any functional area). Or how about an employee broadening his scope by following a course outside his own functional areas to prepare for a future career-change?

My rule of thumb: a bridge-table should reference only "main" objects and not other bridge-tables. (but of course, as with any rule of thumb, you may decide otherwise in a certain situation ).

Marco