Hi,
Can anybody tell me the differences between the above mentioned terms?
Also please tell me if one can be the other and vice versa..please
elaborate with the helpof a table if possible. Also please tellme if
the below statement by me is correct..
a) Any attribute or a collection of attributes which uniquely
identifies the tuples in a relation is called a canditate key.this
candidate key thus can contain a single attribute or a collection of
attributes.
b) one of the attributes is chosen by the DBMS to identify the tuples
uniquely and this attribute is called the primary key.
c) A primarykey is a candidate key.all candidate keys cannot be a
primary key.
Now,,,what is the superkey?

http://groups.google.com/group/comp....56494b68634ee7

--
Anith

A superkey is a set of attributes which uniquely identifies a tuple in a
relation.

A candidate key is an irreducible set of attributes which uniquely
identifies a tuple in a relation.

A composite key is a candidate key that has more than one attribute.

The primary key is a candidate key. Any candidate key can be the primary
key, but usually the candidate key that participates in referential
constraints is designated as the primary key.

(a) is imprecise. A collection is different from a set: it's a multiset.
Also, a candidate key must be irreducible, meaning that if any of the
attributes are excluded, the remaining attributes do not uniquely identify a
tuple.

(b) is incorrect. The database designer, not the DBMS, chooses which
candidate key is primary. In addition, a candidate key can have more than
one attribute, so it's possible to have a composite primary key.

I've addressed (c) above.

A candidate key is a superkey, but a superkey is not necessarily a candidate
key. A superkey may be reducible, meaning that even if one or more
attributes are excluded, the remaining attributes still uniquely identify a
tuple.

"Abhishek" <abhisheksgumadi (AT) gmail (DOT) com> wrote

"Abhishek" <abhisheksgumadi (AT) gmail (DOT) com> wrote:

A superkey can be said to begin with all the attributes in a tuple and
reduce to those attributes which uniquely identify the tuple. So
everything inbetween, as well.

The irreducible superkey, if you will. The candidate key is said to be
that which is one or more attributes which uniquely identify the
tuple. And these attributes cannot be further pared in any way so that
the result would also still uniquely identify that tuple. A composite
key would be your 'collection of attributes'. A composite key is more
than one attribute.

By the machine? Chosen by the machine? You might be referring to an
automatically numbered field, which becomes an artificial primary key,
and unique for any tuple in the relation/table, but with no semantic
tie at all to the other attributes, that is, if the designer selects
it to be the primary key. The machine doesn't do it. If not selected
as such, it's just another attribute. The primary key may be one
attribute, a composite, a candidate key or superkey. It must uniquely
identify the tuple.

Would you say that, now?

And do you have your answer?

Mark Johnson <102334.12 (AT) compuserve (DOT) com> wrote:

Let me add, if it helps to clarify anything:

Primary key - uniquely identified
Superkey - uniquely identifies at a minimum
Candidate - uniquely identifies
Composite - but only if uniquely identifies
Attribute - ""

Superkey - uniquely identifies, and perhaps then some
Candidate - uniquely identifies
Composite - but only if uniquely identifies
Attribute - ""

Candidate Key - uniquely identifies
Composite - but only if
Attribute - ""

Composite Key - may uniquely identify, may not
more than one Attribute

Attribute - may uniquely identify or not
one Attribute

Now that I have understood the different types of keys and their
differences, can you tell me what is a NON-PRIME ATTRIBUTE? Is it an
attribute which is not a candidate key?
Brian Selzer wrote:

Abhishek wrote:
There is no formal distinction between them. Therefore, let's speak of
unique key or just a key. Formally, a key is a functional dependence
from a set of attributes to the whole relation header.

Mikito Harakiri wrote:
To clarify, I don't really understand why some property totally
unrelated to uniquness has to be a part of key name. For example, what
irreducibility of the number of attributes has to do with uniqueness?
Or attribute participation in referential integrity constraint?

Mikito Harakiri wrote:
This is nice and simple, but it slightly bothers me that in most cases,
this describes an FD that has attributes on both the left and right
side of the arrow. (Not that there is anything wrong with that, but
perhaps there is some value to excluding the trivial depedencies?)

What would you say to:

A functional dependency X -> Y, where X and Y are disjoint sets of
attributes, is a key if X union Y = relation header.

Is it always possible to uniquely normalize the set of functional
dependencies such that there are no trivial dependencies?


Marshall

Marshall Spight wrote:
I think you have it backwards. A trivial FD is

header -> any set of attributes

not

a set of attributes -> header