The
identity of an
object.
This is a hotly debated notion in database theory.
Objects have properties (aka attributes). We can determine the attributes of each category of objects; Aristotle tried to do this for the real world,
database designers only have to deal with a small part of it.
This was formalized in the relational database model. It is a mathematical formulation of tables (a.k.a. relations).
For example, a table 'with persons' only lists attributes of persons: their name, address, age, or whatever information he table is supposed to contain. It is in essence a logical model:
Each tuple (row) of the table represents a fact about the world concerning a person. The relational model can only "circumscribe" persons in terms of relationships between attribute values: only attributes (properties) of persons can be referred to in the model, not person objects.
An object, in this context, is something with attributes, but unlike a relational tuple, it is not defined by its attributes: objects can change, through modification of the attribute values, while their identity remains the same. Objects can be referred to, and changes to the object attributes will be reflected wherever it is used.
A relational tuple, by contrast, is a value: it cannot be changed, only replaced with a different tuple. It cannot be referred to.
So much for theory, but in practice, relational databases are full of objects and references, owing to the fact that object identity is easy to fake.
A popular method to simulate objects within the relational model is to use a special attribute, a surrogate identity, that is guaranteed to be different for each tuple, and that is only used in comparisons. This attribute is used whenever a reference to the whole object - in this case, a person - must be made within the model.
This is still a far cry from true objects in the progtramming sense. In programming, objects do not have visible attributes, but methods that can receive messages and act on them.
If an attribute value is used as an object identity,
it must meet the following criteria:
- uniqueness: the system must guarantee that object references remain unique
- opaqueness: the system must guarantee that equality is the other operation available on identities
As an example, URLs do not qualify, because they have meaning: they identify the object's location.