Keys

database systems are particularly good at storing large quantities of data. (Our example
database is not even small, it is tiny!) The DBMS must support rapid searching
among many tuples. This is why relational data models use the notion of a key. In
other words, if we have a value for each of the key attributes we are guaranteed to
find no more than one tuple in the table with that combination of values; it remains
possible that there is no tuple for the given combination. In our example database, the
set TaxId, Surname is a key of the relation PrivatePerson: if we know both a TaxId and
a Surname value, we will find at most one tuple with that combination of values.
Every relation has a key, though possibly it is the combination of all attributes. Such
a large key is, however, not handy because we must provide a value for each of its
attributes when we search for tuples. Clearly, we want a key to have as few as possible
attributes: the fewer, the better.
A key of a relation comprises one or more attributes. A value for these attributes
uniquely identifies a tuple.
If a key has just one attribute, it obviously cannot have less attributes. Some keys have two attributes; an example is the key Plot, Owner of relation TitleDeed. We need both attributes because there can be many title deeds for a single plot (in the case of
plots that are sold often), but also many title deeds for a single person (say, in the
case of wealthy persons). When we provide a value for a key, we can look up the
corresponding tuple in the table (if such a tuple exists). A tuple can refer to another
tuple by storing that other tuple’s key value. For instance, a TitleDeed tuple refers to
a Parcel tuple by including that tuple’s key value. The TitleDeed table has a special
attribute Plot for storing such values. The Plot attribute is called a foreign key because
foreign key it refers to the primary key (Pid) of another relation (Parcel). This is illustrated in the figure below. 

Two tuples of the same relation instance can have identical foreign key values: for
instance, two TitleDeed tuples may refer to the same Parcel tuple. A foreign key is,
therefore, not a key of the relation in which it appears, despite its name! A foreign key
must have as many attributes as the primary key that it refers to.