OK, then I think a tweak to the table structure is in order. Since an asset type can have many PM schedules and the same PM schedule names (PM1, PM2...) can apply to many asset types we have a many-to-many relationship. Additionally, since each combination of PM schedule name and asset type have many PM Tasks and a PM task can apply to many PM scheduleNames/asset type combinations we have a second many-to-many relationship
tblPMScheduleNames
-pkPMSchedule
-PMNumber
tbAssetTypePMScheduleNames
-pkAssetTPMSchNameID primary key, autonumber
-fkAssetTypeID foreign key to tblAssetTypes
-fkPMSchedule foreign key to tblPMScheduleNames
tblPMScheduleTasks
-pkPMSchTaskID primary key, autonumber
-fkAssetTPMSchNameID foreign key to tblAssetTypePMScheduleNames
-fkPMTaskID foreign key to table that holds the various PM tasks
-interval (the mileage or hours of use at which the task must be conducted for the given asset type/scheduleName)
You would then join pkPMSchTaskID in the PMEvent tasks table (as a foreign key) when an actual PM task is conducted.