数据库设计中的关系与数据约束

Question

To simplify the description let's assume we've got a DB model with TimeScopes (ID, start, end) and Processes with FK (TimeScopes.ID), and this is one-to-many relation where all processes holding a reference to the TimeScopes.ID are running within the given time scope.

So first, you define a single time scope and pick multiple processes running at that time scope.

TimeScopes
  |__
     Processes

There are some additional constraints in the application (no DB triggers in the DB so far), like assumptions that TimeScopes are not overlapping - only one TimeScope could be active at the time.

Now I've got a new requirement to add some new Processes that could be initiated at any moment in time without any constraint - so effectively they do not have to, but they could be running simultaneously at the same time (in parallel).

In this case, someone would define the process first and then assign it to such a new, single Process multiple time scopes without a constraint mentioned earlier. So this would be quite the opposite relation one Process to many TimeScopes.

Processes
  |__
     TimeScopes

I'm looking for help and advice on how to solve it?

From the relations perspective, I can adjust the relation between TimeScopes and Processes to many-to-many by adding a table to define relations in both directions.

TimeScopes
  |__
   __ TP-Relations
  |
Processes

What makes me uncertain about that is the additional time constraint from the existing model. That drives me to think about an alternative solution and define maybe a separate tables for NewProcesses and NewTimeScopes

NewProcesses
  |__
     NewTimeScopes

and later combine results between two models in queries by use of UNION statement.

Which seems to be better? Any other or better ideas?

Update/Rephrase the question

Let's say we've got Entities "A" and "B" in many-to-many relation made with additional "AB" (junction) table.

For some records representing A->B in 1-to-many relation, there are some additional constraints about the A records. Let's say we've got some triggers to watch each record in A doesn't cross the boundaries of another A record.

For other records representing B->A in 1-to-many relation these boundaries are not always acceptable so shouldn't be forced/checked.

Question: How to deal with such a problem?

• Modify the model/relations, how?
• Modify the triggers? but is it even possible on the DB level to recognise that some records would be entered for A->B vs B->A relations?

Answer 1

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.