A set of attributes that includes a key is called a superkey, short for "superset of a key". In this way, every key is a superkey. However, some superkeys are not (minimal) keys. Note that every superkey satisfies the first condition of a key: it functionally determines all other attributes of the relation. However, a superkey need not satisfy the second condition; minimality.

Example (a) :  In the relation of example in "Keys of Relations" , there are many superkeys. Not only is the key

{title, year, starName}

a superkey, but any superset of this set of attributes, such as

{title, year, starName, length, studioName}

is a superkey.

Discovering Keys for Relations

When a relation schema was developed by converting an E/R design to relations, we can often predict the key of the relation. Our first rule about inferring keys is:

●  If the relation comes from an entity set then the key for the relation is the key attributes of this entity set.

Example (b) :  In "From Entity Sets to Relations" example,  we described how the entity sets Movies and Stars could be converted to relations. The keys for these entity sets were {title, year} and {name}, respectively. Therefore, these are the keys for the corresponding relations, and

Movies(title, year, length, filmType)
Stars(name, address)

are the schemas of the relations, with keys indicated by underline.

Our second rule deals with binary relationships. If a relation R is constructed from a relationship, then the multiplicity of the relationship affects the key for R. There are three cases:

●  If the relationship is many-many, then the keys of both connected entity sets are the key attributes for R.

●  If the relationship is many-one from entity set E1 to entity set E2, then the key attributes of E1 are key attributes of R, but those of E2 are not.

Other Key Terminology

●  If the relationship is one-one, then the key attributes for either of the connected entity sets are key attributes of R. Thus, there is not a unique key for R.

Example (c) :  Example (a) in "From E/R Relationships to Relations" discussed the relationship Owns, which is many-one from entity set Movies to entity set Studios. Thus, the key for the relation Owns is the key attributes title and year, which come from the key for Movies. The schema for Owns, with key attributes underlined, is thus

Owns(title, year, studioName)

On the contrary, example (b) in "From E/R Relationships to Relations" discussed the many-many relationship Stars-in between Movies and Stars. Now, all attributes of the resulting relation are key attributes.

Stars-in(title, year, starName)

In fact, the only way the relation from a many-many relationship could not have all its attributes be part of the key is if the relationship itself has an attribute. Those attributes are omitted from the key.

Finally, let us examine multiway relationships. Since we cannot explain all possible dependencies by the arrows coming out of the relationship, there are situations where the key or keys will not be clear without thinking in detail about which sets of entity sets functionally determine which other entity sets. One guarantee we can make, however, is

●  If a multiway relationship R has an arrow to entity set E, then there is at least one key for the corresponding relation that excludes the key of E.