E-R Schema in second normal form

Question

I have a doubt on a table in my ER schema and the second normal form. The table has an attribute that depends on another one and I don't know if this causes problems with the normalization.

The table structure is like this:

| contract_id | start_date | end_date |

The primary key is *contract_id*. The problem is that the value of *end_date* is exactly 1 year after the *start_date*.

Rows example:

| 1 | 2013-01-01 | 2014-01-01 |
| 2 | 2012-02-03 | 2013-02-03 |

Is this table in 2NF?

Answer 1

I don't see why it shouldn't be 2NF. For 2NF to hold, there should not be a partial dependency on any column in a compound/composite primary key (which is not the case here).

Your question is more likely a concern for 3NF.

Answer 2

It is not covered by 2NF or 3NF but this model violates Domain/Key normal form. Simply remove one of attributes if interval is always is a year or add a check constraint.
eg CHECK (end_date - start_date = 365), 365 is financial year, calendar year is not a constant.

Answer 3

A calculated column from other columns in the same row violates 3-NF . Some would tell you to not store the calculated column in your database to comply with 3-NF and that is indeed valid for the current model. However, you have to assess whether this is valid for your business or not. Suppose in 3 months time, the business rules change and the end_date is no longer equal to the start_date+1 year, what will you do?

Answer 4

It is arguably not 2NF (presumably start_date is unique), but it is not 3NF, because you could use the expression

adddate(start_date, interval 1 year)

Or better create a view with end_date being this expression.

You also must ask yourself about data integrity: what happens to your database if through same mistake your end date is not one year after the start date? If the end date is calculated, such a situation is not possible - you get data integrity built in.

If end date is a separate column, every insert and update of these columns should be checked for correctness, which is more work and potentially more bugs.

Lastly, each row will be smaller if end date is not stored, which will give a small performance gain, although the gain may be insignificant.

Answer 5

that doesn't violate 2NF but it does 3NF. you don't need to store a coputational field in the database. that being said you don't have all the information you need to compute the value in the database either. I would drop the end_date as stated above, but i would add a contract_term field. it would be easy to do now that they are all 1 year, or 12 months, or however you chose to compute it, as opposed to in the future when they may change. then you will be able to compute the expiration date faithfully even if the business needs change, plus you are not storing a computed field. also, since contract_term describes the entity you are not violating 2NF or 3NF.

Answer 6

If start_date->end_date and end_date->start_date then it follows that (start_date,end_date) is not a candidate key because that composite would not be a minimal superkey. Therefore 2NF is satisfied because no proper subset of any candidate key is a determinant.

3NF means that for every dependency you require to be satisfied either the determinant is a superkey or the dependent attributes are part of a candidate key. The relevant question therefore is whether start_date and end_date are both candidate keys. If and only if they are then 3NF is satisfied. If start_date and end_date are nonprime (not candidate keys) then your table satisfies 2NF but not 3NF.