First of all, while I have no issues with the Employee_FunctionalArea construct used in this article I wish we could all reach an agreement on what to call a table used to resolve many-to-many relationships. I've heard "bridge" table, "cross-walk", "cross-reference", and "link" table to name a few. As one poster mentioned, in modeling terminology these are often referred to as "associative", "intersectional", "resolution" or "junction" entities depending on whose book you read.

From a design point of view I think I might take a simpler approach to solving the training issue. We know that because "the training item that the employee needs to be trained on is specific to the functional area in which they work" there is a one-to-one relationship between functional_area and training_course so I would add the FK_TrainingCourse to the FunctionalArea table.

Table Name: FunctionalArea

Column Name Data Type

ID int (auto-increment, Primary Key)

Name varchar(50)

FK_TrainingCourse int (relates to the TrainingCourse table)

I would then add TrainingDate to the bridge table. It is, after all, an attribute of the Employee/FunctionalArea relationship.

Table Name: Employee_FunctionalArea

Column Name Data Type

ID int (auto-increment, Primary Key)

FK_Employee int (relates to the Employee Table)

FK_FunctionalArea int (relates to the FunctionalArea Table)

TrainingDate DateTime

This way you don't need the Employee_FunctionalArea_TrainingCourse table at all.

Just my two cents.