0

I'm studying a DB course and I found this table:

table

In this exercise, the objective is to determine whether the table has redundancy or not.

According to the definition of redundancy

Data redundancy occurs in database systems which have a field that is repeated in two or more tables

Redundancy DOES exists in the table,FECHA_INICIO(START_DATE) and FECHA_FIN (END _DATE) attributes, but should this attributes be considered as redundant?

Dates are quite volatile and I'm not quite convinced that those columns should be treated as redundant?

Any ideas on whether this table contains redundancy or not?

  • 1
    I'm going to go out on a limb and say that there is no redundancy here. Start dates and End dates are frequently used in databases. – beeks Apr 6 '14 at 0:31
  • No there is no redundancy in your table. Your table is fine. – nmad Apr 6 '14 at 0:42
  • You keep the source of your definition of redundancy secret but from this definition you don't have bother about redundancy because you do not have two or more tables. – miracle173 Apr 6 '14 at 6:24
  • If you cannot change an arbitrary column of an arbitrary row to another value then I think one have redundant fields. But then you have a functional dependency too. Are you familiar with the concept of fundcional dependencies and normalisation? – miracle173 Apr 6 '14 at 6:36
  • 1
    Where did you find that definition? It is flawed -- think UserID appearing in multiple tables. – Damir Sudarevic Apr 6 '14 at 13:55
4

Redundancy does not mean:

  • Columns that have the same data type
  • Columns (or rows) that have the same data value (if this is coincidental)
  • Columns that are foreign keys that link a child table to its parent (including the same data value as FK and PK in the respective tables)

Redundancy is not about columns or rows for that matter. Redundancy is about functional dependencies. If you have predicates (i.e. columns) that are transitively dependent, then you have redundancy.

Hunting for redundancy is a bad approach when optimizing a logical data model. Trying to decide what is and isn't redundant is tricky and frankly a little bit beside the point. Focus on normalization. This will eliminate your redundancy along with other potential problems along the way.

When you move from logical model to physical database, you can then determine whether managing some redundancy is worthwhile for some reason.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.