functional dependencies of a table having independent attributes

Question

i have doubt about independent attributes(like constant column) in a table. what should be the primary key and fds for the following example:

let a,b,c,d,e are the attributes and a,b,c uniquely identifies a row and d,e are the independent columns. then what should be the key attributes and what are the fds

Answer 1

let a,b,c,d,e are the attributes and a,b,c uniquely identifies a row and d,e are the independent columns. then what should be the key attributes and what are the fds

If ABC uniquely identifies a row, and if no subset of ABC uniquely identifies a row, then ABC is an irreducible superkey, also known as a candidate key. Assuming that ABC is the only candidate key, and assuming that ABC is also the only determinant, then these are the FDs.

• ABC->D
• ABC->E

ABC->ABC is a trivial dependency. Trivial dependencies are usually omitted.

What does assuming that ABC is the only determinant mean? It means that you don't have any other unexpressed FDs, like D->E, or AB->D, or D->A.

Answer 2

An attribute is usually said to be independent with respect to some set of dependencies if it does not appear on the left hand side of any dependency in that set or on the right hand side of any (non-trivial) dependency in that set. Independent doesn't necessarily mean constant, it just means the attribute is not determined by other attributes.

The "right" (5th Normal Form) way to model an attribute which is independet of any other attribute in a schema is to put it in a table of its own.

A distinction ought to be made between the set of dependencies intended to be modelled by any table and the set of dependencies actually in effect in a table. Your question isn't exactly clear because you say that d,e are "independent" attributes within a table and then ask what the dependencies are. If a,b,c is a (super)key as you say it is then the de facto dependency in effect is that all attributes in the table are determined by a,b,c - so d and e are not "independent" at all.

If on the other hand you didn't intend to implement any dependencies on d or e then you could make (a,b,c,d,e) a candidate key (so a,b,c alone are no longer uniquely identifying) OR you could decompose d and e separately into their own tables.