It is a unique identifier for

either an entity in the

modeled world or
an object in the database.


the value is unique system-wide,
hence never reused
the value is system generated
the value is not manipulable by
the user or application



the value contains no semantic
meaning
the value is not visible to the user
or application
the value is not composed of
several values from different
domains.

In a current database, the surrogate
key can be the primary key, generated
by the database management
system and not derived from any
application data in the database. The
only significance of the surrogate key
is to act as the primary key.

A surrogate key is frequently a sequential
number (e.g. a Sybase or SQL Server "identity
column", a PostgreSQL or Informix serial,
an Oracle SEQUENCE or a column
defined with AUTO_INCREMENT in MySQL) but
doesn't have to be. Having the key independent
of all other columns insulates the database
relationships from changes in data values or
database design (making the database
more agile) and guarantees uniqueness.

In a temporal database, it is necessary
to distinguish between the surrogate
key and the business key. Every row
would have both a business key and a
surrogate key. The surrogate key
identifies one unique row in the
database, the business key identifies
one unique entity of the modeled
world.

One table row represents a slice of time holding all
the entities attributes for a defined time span. Those
slices depict the whole lifespan of one business
entity. For example, a table Employee Contracts may
hold temporal information to keep track of contracted
working hours. The business key for one contract will
be identical (non-unique) in both rows however the
surrogate key for each row is unique.