Table design help: Need multiple different entities pointing to an an entity grouping

Question

I can't for the life of me get this through my head. It seemed so simple at first and now I've stared at it for too long, I can't see the forest for the trees.

In essence we have Day divisions, these are abitrary...

ID  Name    Start  End
1   Name1   1300   1400
2   Name2   13:30  19:30
3   Name3   20:00  21:30 

etc

We want to be able to configure the days of a week with any combination of these day divisions, so we have the WeekConfigurations table

ID  ConfigurationID  DayOfWeek   DayDivisionID   Order
1   1                1           1               1
2   1                1           2               2
3   1                2           2               1
4   1                2           3               2
5   2                1           1               1
6   2                3           2               1
7   2                3           3               1

Now we want other entities (Person, Office etc) to have a certain week configuration assigned to them. And this is where I'm coming un-stuck. The configurationID I want to assign isn't the primary key so I can't enforce the referential integrity between the entities and a configuration.

Can anyone point me in the right direction? Something about the WeekConfiguration table smells funny to me, but I just can't see it.

PS: Sorry, I had a nice diagram to illustrate but I'm a newbie and can't add it

Answer 1

At the logical level, you have a "configuration" and a set of "configuration items" under that configuration. So instead of just one configuration table, use two:

In this design, the ConfigurationId is a primary key (of Configuration table), so you can directly use it as a parent endpoint of foreign keys.

The ConfigurationItem PK ensures a single day division can be used in at most one day of week per configuration and the alternate key U1 ensures it is unambiguously ordered (within the same day of week and configuration).

I have also chosen to avoid a surrogate PK in ConfigurationItem. You can easily add it (and make the existing PK alternate) if necessary - e.g. if you have additional FKs you didn't mention or use an ORM that doesn't play well with composite PKs.

Answer 2

Yes. WeekConfiguration should be split into two tables.

To enforce referential integrity you need a table in which there is exactly one record (and one ID) per week configuration; this table should have the column that you call ConfigurationID and maybe some kind of description.

The other table (we might call it `WeekConfigurationDetail) should store detail records, day divisions that the week configurations are composed of. While the columns would be similar to your existing table, its primary key (ConfigurationID again) would itself be a foreign key to the main WeekConfiguration table. In the same way, any other table (entities) would be able to foreign reference that one.

Even if you had only one column in the WeekConfiguration table, a meaningless ID, you still need the table to ensure referential integrity.

This database design pattern is called master-detail, or also parent-child.