Primary and Foreign Keys
Primary and foreign keys are the most basic
components on which relational theory is based.
Primary keys enforce entity integrity by
uniquely identifying entity instances. Foreign
keys enforce referential integrity by completing
an association between two entities. The next
step in building the basic data model to
- identify and define the primary key
attributes for each entity
- validate primary keys and relationships
- migrate the primary keys to establish
foreign keys
Define Primary Key Attributes
Attributes are data items that
describe an entity. An attribute instance
is a single value of an attribute for an
instance of an entity. For example, Name and
hire date are attributes of the entity EMPLOYEE.
"Jane Hathaway" and "3 March 1989" are instances
of the attributes name and hire date.
The primary key is an attribute or
a set of attributes that uniquely identify a
specific instance of an entity. Every entity in
the data model must have a primary key whose
values uniquely identify instances of the
entity.
To qualify as a primary key for an entity, an
attribute must have the following properties:
- it must have a non-null value for each
instance of the entity
- the value must be unique for each
instance of an entity
- the values must not change or become
null during the life of each entity
instance
In some instances, an entity will have more
than one attribute that can serve as a primary
key. Any key or minimum set of keys that could
be a primary key is called a candidate key.
Once candidate keys are identified, choose one,
and only one, primary key for each entity.
Choose the identifier most commonly used by the
user as long as it conforms to the properties
listed above. Candidate keys which are not
chosen as the primary key are known as alternate
keys.
An example of an entity that could have
several possible primary keys is Employee. Let's
assume that for each employee in an organization
there are three candidate keys: Employee ID,
Social Security Number, and Name.
Name is the least desirable candidate. While
it might work for a small department where it
would be unlikely that two people would have
exactly the same name, it would not work for a
large organization that had hundreds or
thousands of employees. Moreover, there is the
possibility that an employee's name could change
because of marriage. Employee ID would be a good
candidate as long as each employee were assigned
a unique identifier at the time of hire. Social
Security would work best since every employee is
required to have one before being hired.
Composite Keys
Sometimes it requires more than one attribute
to uniquely identify an entity. A primary key
that made up of more than one attribute is known
as a composite key. Figure 1 shows an
example of a composite key. Each instance of the
entity Work can be uniquely identified only by a
composite key composed of Employee ID and
Project ID.
Figure 1: Example of Composite Key
WORK
| Employee ID |
Project ID |
Hours_Worked |
| 01 |
01 |
200 |
| 01 |
02 |
120 |
| 02 |
01 |
50 |
| 02 |
03 |
120 |
| 03 |
03 |
100 |
| 03 |
04 |
200 |
Artificial Keys
An artificial keyis one that has no
meaning to the business or organization.
Artificial keys are permitted when 1) no
attribute has all the primary key properties, or
2) the primary key is large and complex.
Primary Key Migration
Dependent entities, entities that depend on
the existence of another entity for their
identification, inherit the entire primary key
from the parent entity. Every entity within a
generalization hierarchy inherits the primary
key of the root generic entity.
Define Key Attributes
Once the keys have been identified for the
model, it is time to name and define the
attributes that have been used as keys.
There is no standard method for representing
primary keys in ER diagrams. For this document,
the name of the primary key followed by the
notation (PK) is written inside the entity box.
An example is shown in Figure 2A.
Figure 2: Entities with Key
Attributes
Validate Keys and Relationships
Basic rules governing the identification and
migration of primary keys are:
- Every entity in the data model shall
have a primary key whose values uniquely
identify entity instances.
- The primary key attribute cannot be
optional (i.e., have null values).
- The primary key cannot have repeating
values. That is, the attribute may not
have more than one value at a time for a
given entity instance is prohibited.
This is known as the No Repeat Rule.
- Entities with compound primary keys
cannot be split into multiple entities
with simpler primary keys. This is
called the Smallest Key Rule.
- Two entities may not have identical
primary keys with the exception of
entities within generalization
hierarchies.
- The entire primary key must migrate from
parent entities to child entities and
from supertype, generic entities, to
subtypes, category entities.
Foreign Keys
A foreign key is an attribute that
completes a relationship by identifying the
parent entity. Foreign keys provide a method for
maintaining integrity in the data (called
referential integrity) and for navigating
between different instances of an entity. Every
relationship in the model must be supported by a
foreign key.
Identifying Foreign Keys
Every dependent and category (subtype) entity
in the model must have a foreign key for each
relationship in which it participates. Foreign
keys are formed in dependent and subtype
entities by migrating the entire primary key
from the parent or generic entity. If the
primary key is composite, it may not be split.
Foreign Key Ownership
Foreign key attributes are not considered to
be owned by the entities to which they migrate,
because they are reflections of attributes in
the parent entities. Thus, each attribute in an
entity is either owned by that entity or belongs
to a foreign key in that entity.
If the primary key of a child entity contains
all the attributes in a foreign key, the child
entity is said to be "identifier dependent" on
the parent entity, and the relationship is
called an "identifying relationship." If any
attributes in a foreign key do not belong to the
child's primary key, the child is not identifier
dependent on the parent, and the relationship is
called "non identifying."
Diagramming Foreign Keys
Foreign keys attributes are indicated by the
notation (FK) beside them. An example is shown
in Figure 2 (b) above.
Summary
Primary and foreign keys are the most basic
components on which relational theory is based.
Each entity must have a attribute or attributes,
the primary key, whose values uniquely identify
each instance of the entity. Every child entity
must have an attribute, the foreign key, that
completes the association with the parent
entity.
The next step in building the model is to add Attributes
to the model. |