The ERM for the database follows:

$\backslash$table$[[$ENTITY$,$RELATIONSHIP,CONNECTIVITY,ENTITY$],[$INSTRUCTOR$,$teaches,$1$:$M,$CLASS$],[$COURSE$,$generates,$1$:$M,$CLASS$],[$CLASS$,$is listed in$,1$:$M,$ENROLL$],[$TRAINEE$,$is written in$,1$:$M,$ENROLL$]]$

The following business rules will help you better understand the relationships:

A COURSE does not necessarily generate a class during each training period. $($Some courses may be taught every other period or during some other specified time frames. Therefore, it is reasonable to assume that CLASS is optional to COURSE.

Each CLASS must be related to a COURSE. $($The class must cover designated course material!$)$ Therefore, COURSE is mandatory to CLASS.

Some instructors may teach a class every other period or even rarely. Therefore, it is reasonable to assume that CLASS is optional to INSTRUCTOR during any enrollment period. This optionality makes sense from an implementation point of view, too. For example, if you appoint a new instructor, that instructor will not $-$ yet $-$ have taught a class.

While a CLASS may have an INSTRUCTOR, sometimes a class is not taught due to low interest. As such, not all classes have enrollment records $($i$.$e$.,$ data in ENROLL$).$

Not all trainees are likely to be enrolled in classes during some time period. In fact, in a real world setting, many trainees are likely to get informal $"$on the job" training without going to formal classes. Therefore, it is reasonable to assume that ENROLL is optional to TRAINEE.

You cannot create an enrollment record without having a trainee. Therefore, TRAINEE is mandatory to ENROLL.

Here are the PK and FK attributes for each entity:

$\backslash$table$[[$ENTITY$,$PK$,$FK$,\backslash$table$[[$PKIFK$],[$COMBINATIONS$]]],[$INSTRUCTOR$,$INSTR$\_$NUM,,$],[$COURSE$,$CRS$\_$CODE,,$]]$