Unrelated tables and time intervals

Question

I am going to comment on the scenario that I currently have when designing my database.

I have the following tables:

user (id, name, lastname)

role (id, name)

user_role (user_id, role_id, from_date, to_date)

period (id, name, from_date, to_date)

The period table serves as a data master to know the name of the periods that I define in my application.

In this case I mention only the user, role and user_role tables, but there are many more tables that have periods.

The intention of the period table is to act as a labeling system for the different periods that exist in the tables of my model. This table is not related in any way by any foreign key with other tables. To do the searches and relate other tables to this, a join is made using dates from and dates to.

For example, a tuple of the user_role table can have a date from and a date until that covers several periods defined in the period table, so it would be labeled with the names of the periods it comprises.

Is it okay for the period table to be an unrelated table? It only serves to give names to the periods, that's why I put it this way. Can you think of another better way to raise it? Should the period table be related to the other tables in some other way?

Thanks in advance.

Answer 1

You should distinguish between the logical and the physical data models. The logical model documents how you users think about the objects and concepts in their world, and how those things interact. The physical models says how you, as a programmer, implement those business entities in well-performing software.

To the users of your system the user_role entity type covers a number of periods, and those periods' names are held in an entity type called "period." At the logical level there is a relationship between those two entity types because one holds the names for the other. A user would expect to reference the period entity in order to complete the information held in the user_role entity.

When you come to implement that logical model in a specific DBMS likely you will implement each entity type as a table. Similarly you could choose to declare the logical relationship as a physical foreign key constraint and have the DBMS software enforce it for you. Or you could choose not to.

There are good reasons to declare a foreign key, and good reasons not to. There is nothing that says you have to have it in your database design. If you choose not to, however, you must find another way of doing the job that a foreign key does (ensuring data integrity) or accept the risk of not doing that job. If you do implement it you must accept the extra work required at design time (period - user_role is likely a many-to-many and so will require further intersection tables) and at run time (to verify the foreign key constraint).

As a concrete example, I have worked on many systems which include created_by_user and modified_by_user in every table. I would not declare these as foreign keys to the user table because they to not support the integrity of the business data - they are, at best, handy debugging aids for programmers. These systems do have columns like invoice.written_of_by_user and grant.approved_by_user. These columns are central to the purpose of the systems which hold them. Having good data in them is vital, and maintaining the integrity of that data for seven years is a legal requirement. For such columns I would declare foreign keys.

There is no one answer to this which is correct for all systems. Weigh the costs and benefits, discuss with the users and project sponsor, and be prepared to change your implementation if new considerations arise.

Answer 2

Thank you for your response on my queries.

My thoughts on this:

1. Periods are only to label your data
2. It is not labeling every data of your database
3. Since as per your clarifications "When inserted, it is not checked if there is a period to insert the information", periods may overlapped each other
4. Query is not essentially labeling every data with a periods
5. Database is very small in size,

Linking a table to others needs some sort of consistency which is not available in this case. Seeing these inputs, IMHO, we can safely keep this table as separate entity.

From Performance aspects, we can make better indexes based on our application's need on period table to avoid any bottleneck.

Thank you,

Sanjeeva