Relations vs data constraints in database design

Based on the comments, it appears the following is true:

• A timescope can have many processes
• A process can belong to many timescopes
• A timescope should not have an overlapping start or end with another timescope if the timescope has more than one process.

I would separate this out into two questions:

How should I model the relationship between process and timescope?

It seems that this is a straightforward many-to-many relationship, so I would include a joining table as you suggest.

How should I ensure the business rule about overlapping timescopes?

I don't think you can enforce this through the entity relationships in your model. You then have a few options - if you must implement it at the database level, a trigger on the relation table should do the job - your rule applies only if there is more than 1 process for a given timescope, which will cause an insert or update event on your join table.

I am not a huge fan of triggers - they are hard to test, hard to debug, and can lead to performance problems. If at all possible, I'd implement this in the application layer.

Should you store different types of timescopes/processes in different tables?

This is partly philosophical, partly practical. In general, you should store similar types of entity in the same table. Especially if they vary in behaviour, but not attributes; don't repeat yourself and all that.

If you have different validation rules, but identical attributes, I'd keep them in a single table.

This is all subject to "understandability" - if your system describes mammals, keeping "humans" and "cats" in the same table with a type discriminator is probably fine. If your system describes "humans" and "tables", the fact that both have "leg_count" attributes is not a reason to keep them in the same table.