Object Identity
Setrag N. Khoshafian and George P. Copeland
Mlcroelectronles And Computer Technology Corporation
9430 Research Blvd.
Austin, Texas 78759
Abstract
Identity is that property of an object which distinguishes
each object from all others. Identity has been investigated
almost independently in general-purpose programming
languages and database languages. Its importance is growing
as these two environments evolve and merge.
We describe a continuum between weak and strong
support of identity,and argue for the incorporationof the
strong notion of identity at the conceptual level in languages
for general purpose programming, database systems and their
hybrids. We define a data model that can directly describe
complex objects, and show that identity can easily be
incorporated in it. Finally, we compare d~erent
implementation schemes for identity and argue that a
surrogate-based implementation scheme is needed to support
the strong notion of identity.
1 Introduction.
With the advent of increased efficiency of computer
systems, the sophistication and demand of the users of
these systems has been increasing. We have seen some
significant changes in both general-purpose programming
and database languages. In general-purpose
programming, we went from assemblers to high-level
languages and, more recently, to logic, functional and
object-oriented languages. In database languages, we
went from navigational to more declarative relational
models. In more novel applications, such as CAD/CAM,
document retrieval, expert systems and decision support
systems, we are realizing that there are a host of powerful
data modeling concepts which need to be introduced in
both programming languages and database models. One
of these concepts is the need to model arbitrarily complex
and dynamic objects with versions. A more specific need
in this representation is the ability to distinguish objects
Permissionto copywithoutfee all or part of this material is grantedwovided
that the copiesare not madeor distributed for directcommercialndvantqe,
the ACMcopyrightnoticeand the title of the publicationand its dateappear,
and noticeis given that copyinsis by permimonof the Amoc/ationfor
ComputingMachinery.To copyotherwise,or to republish,requiresa fee and/
or weeiflcpennmion.
O 1986 ACM 0-89791-204-7/86/0900-0406 75¢
406 OOPSLA '86 Procsedlngs
from one another regardless of their content, location or
addressability, and to be able to share objects. In this
paper we concentrate on a powerful concept called object
identity which enables us to realize this goal.
Every language must have some way to tell one object
from another. Identity is that property of an object which
distinguishes it from all other objects. Most prolpramming
and database languages use variable names to distinguish
temporary objects, mixing addressability and identity.
Most database systems use identifier keys (i.e., attributes
which uniquely, identify a tuple) to distinguish persistent
objects, mixing data value and identity. Both of these
approaches compromise identity. Object.oriented
languages employ separate mechanisms for these
concepts, so that each object maintains a separate and
consistent notion of identity regardless of how it is
accessed or how it is modeled with descriptive data. This
paper focuses on the identity aspects of languages that
model both temporary and persistent data.
Section 2 describes the importance of identity in both
programming and database environments, as well as the
need to have a consistent notion of identity in
environments which attempt to merge temporary and
persistent data. A continuum between weak and strong
support of identity is described, and an argument is made
for the importance of incorporating the strong notion of
identity at the conceptual level. Section 3 defines an
object model that can directly describe complex objects,
and shows that identity can easily be incorporated in it.
Section 4 compares the various implementation
techniques for identity based on how well they preserve
identity when objects are modified and physically moved,
and argues that a surrogate-based implementation
scheme is needed to support the strong notion of identity.
Implementation of the object model using surrogates is
discussed. Section 5 provides a summary.
2 The Importance Of Object Identity
Identity has been investigated almost independently in
general-purpose programming languages and database
languages. Its importance is growing as these two
environments evolve and merge.
Sq:~ember 1986
 This section describes a continuum between weak and
strong support of identity. We argue for the incorporation
of the strong notion of identity at the conceptual level in
languages for general-purpose programming, database
systems and their hybrids.
2.1 Degrees Of Support Of Identity
There are at least two dimensions involved in the
support of identity, the representation dimension and the
temporal dimension. Figure 1 illustrates this identity
space, populated with some example languages. Note
that when a language includes a stronger support of
identity in either dimension, it is not repeated at the
weaker levels.
REPRESENTATION
& identity in the representation dimension.
built-in -~ Smailtaik-80 RM/T OPAL
GEM
Pascal
u~r-
Proiog
supplied - SQL UNIX shell
name
QBE
SQL
data value- QBE TEMPORAL
I I
I "-
within a between between
program or transactions structural
transaction reorganizations
temporary data persistent data
FIGURE 1: Languages In The Identity Space
The representation dimension distinguishes languages
based on whether they represent the identity of an object
by its value (e.g., identifying employees by social security
number), by a user-defined name (e.g., variable names,
user-defined file names, etc.), or built into the language
(e.g., Smalltalk-80 [Goldberg and Robson 1983]). Going
upward in this dimension indicates stronger support of
identity. A language providing a stronger notion of
identity in this dimension must maintain its representation
of identity during updates, use identity in the semantics of
its operators, and provide operators to manipulate
identity.
The temporal dimension distinguishes languages
based on whether they preserve their representation of
identity within a single program or transaction, between
transactions, or between structural reorganizations. An
example of structural reorganization is schema
reorganization in databases [Sockut 1985]. Going to the
right in this dimension indicates stronger support of
identity. A language providing stronger identity in the
temporal dimension must employ more robust
implementation techniques to preserve its representation
of identity.
September1986 OOPSLA~6 Proceedings
2.Z Identity In Progremmlng Languages
Most general-purpose programming languages are
designed without the notion of persistent data in mind.
For this reason, they provide weak support of identity in
the temporal dimension. As far as the language is
concerned, data lives only during the execution of a
program. A file system, which is not part of the
language, is used for any persistent data. Input and
output is usually designed for user interaction, that is, to a
screen or printer, or from a keyboard or mouse. Then
this same input and output model is applied, as an
afterthought, to file system transfers. The structures
supported in the virtual address space of the program are
usually not supported in the file system.
Programming languages vary in their support of
Most
programming languages and file systems employ
user-defined names (i.e., variables in languages and file
names in files systems) to represent identity. The actual
binding of an object to its name could be either dynamic
(i.e., at run-time) or static. Figure 1 includes Pascal
[Wirth 1971] and Prolog [Colmerauer 1975] as
representatives of these languages. This approach mixes
addressability and identity, although the concepts are
quite different. Addressability is external to an object.
Its purpose is to provide a way to access to an object
within a particular environment and is therefore
environment dependent. Identity is internal to an object.
Its purpose is to provide a way to represent the
individuality of an object independently of how it is
accessed. An address-based identity mechanism
compromises identity. Object-oriented languages, such
as Smalitalk-80, provide separate mechanisms for these
concepts so that neither is compromised.
There are practical limitations to the use of variable
names without some built-in representation of identity
and operators to test and manipulate this representation at
an abstract level. One problem is that a single object may
be accessed in different ways and bound to different
variables without having a way to find out if they refer to
the same object [Saltzer 1978]. For example, an
employee object may be accessed as the vice president of
sales and bound to the variable X. The same employee
object may be accessed as an employee with a
salary>S60,000 who is stationed in Austin and bound to
the variable Y. Smalltalk-80 provides a simple identity
test with the expression X==Y, which is different from the
equality test X=Y. Unix [Ritchie and Thompson 1974]
has a built-in representation for file identit~ to support
links between files, but provides no way to test directly
whether two files arrived at by different paths are the
Sglrle.
Given that such built-in support for identity is
provided, adequate operators to manipulate identity are
needed. For example, two objects with separate identity
may later be discovered to be the same (the murderer is
the butlert) and therefore need to be merged. Codd
[1979] has argued for a "coalescing" operator in RM/T
which merges identity. Different copy operators are also
needed to indicate the degree of copying vs. sharing.
Smalltalk-80 provides a "shallow copy" operator and a
407
"deep copy" operator in addition to simple assignment.
For example, suppose the value of Y is a set. Assigning
Y to X causes X to share the same set object as Y.
Assigning a shallow copy of Y to X causes X to be a new
set object with its own identity, whose elements are
shared with those in Y. Assigning a deep copy of Y to X
causes X to be a new set object with its own identity,
whose elements are new objects with their own identity,
but which have the same values as those of Y.
2.3 Identity In Database Languages
Database languages are designed to support large and
persistent data that models large and persistent
real-world systems. These characteristics require strong
support of identity in both the representation and
temporal dimensions.
Every real-world object is an individual. That is,
there is something unique about everything. We have
often heard this pointed out about humans, as well as
such simple and plentiful objects as leaves, grains of
sand, blades of grass and snow flakes. When we model
real-world objects with some particular purpose in mind,
however, we only include some subset of that object's
description in the model. This subset may not be
complete enough to capture the object's uniqueness. In
some cases uniqueness is external (e.g., an object is
unique if it has some local attribute values and belongs to
a different set, or is related to a different object). This
problem arises in databases, as well as in many other
computer systems, because they attempt to model
real-world systems. Smith and Smith [1978] have argued
for the principle of individual preservation for databases,
which states that "every user-invokeable update operation
must preserve the integrity of individuals". If the concept
of identity is "built into a language, then an object's
uniqueness is modeled even though its description is not
unique.
Codd [1970] introduced the notion of user-defined
identifier keys to represent the identity of an object. An
identifier key is some subset of the attributes of an object
which is unique for all objects in the relation. This
representation of identity is supported in many existing
database systems. ]=or example, Figure 1 includes SQL
[Chamberlin and Boyce 1974] and QBE [Zloof 1975] as
representatives of these systems. Both languages use
identifier keys to identify persistent objects. SQL uses
tuple variables and QBE uses domain variables, as does
Prolog, to identify temporary objects. There are several
problems with identifier keys which are due to the fact
that the concepts of data value and identity are mixed.
One problem is that identifier keys cannot be allowed
to change, even though they are user-defined descriptive
data. For example, a department's name may be used as
the identifier key for that department and replicated in
employee objects to indicate where the employee works.
But the department name may need to change under a
company reorganization, causing a discontinuity in
identity for the department as well as update problems in
all objects which refer to it.
408 00PSLA ~6 ProcNdlogs
A second problem is that identifier keys cannot
provide identity for every object in the relational model.
Each attribute or meaningful subset of attributes cannot
have identity. For example, an employee object may have
an attribute describing the employee's spouse by his or
her first name. Later, the spouse also becomes an
employee, causing a discontinuity in identity for the
spouse.
A third problem is that the choice of which attribute/s
to use for an identifier key may need to change. For
example, RCA may use an employee numbers to identify
employees, while General Electric may use social security
numbers for the same purpose. A merger of these two
companies would require one of these to change, causing
a discontinuity in identity for the employees of one of the
companies.
A fourth problem is that the use of identifier keys
causes joins to be used in retrievals instead'of path
expressions, which are simpler, as in GEM [Zaniolo
1983] and OPAL [Copeland and Maier 1984]. For
example, suppose we have an employee relation
employee[name, SS#, birthdate, assignment] and a
department relation department[name, budget, location],
and the assignment attribute establishes a relationship
between an employee and a department. Using identifier
keys, assignment would have as its value the identifier key
of the department, say name. A retrieval involving both
tuples would require a join between the two tuples. Using
tuple variables, a retrieval might be
SE/.~CT E.name, D.Iocation WHERE
E.assignment=D.name
& E IN employee & D IN deparunent,
where E and D are tuple variables. Using domain
variables, the retrieval would be
[X, Z] <== employee[X, -, -, Y], department[Y, -, Z],
where X, Y and Z are domain variables. Using built-in
identity, assignment would have as its value a department
tuple. Unlike strict hierarchical database systems, the
department tuple could also be the value of other objects
without either being owned by any object or being
replicated, forming a directed graph structure. Using
tuple variables, the retrieval would be
SELP_.CI' E.name, E.assignment.location WHERE E IN
employee.
Using domain variables, the retrieval would be
IX, Z] <== employee[X, -, -, department[-, -, Z]].
The identifier key approach requires explicitly introducing
the additional tuple variable D or domain variable Y for
the join. The built-in identity approach has some of the
advantages of the universal relation approach (i.e., no
joins for entity relationships) but without the
disadvantages of requiring unique attribute names
(because nested names are used) and occasionally having
ambiguous paths (since paths are specified) [Kent 1981,
Maier et al. 1984]. Note that with built-in identity,
hierarchical structures are possible without the
undesirable insertion and deletion anomalies described by
Codd [1971].
~ 1986
 Kent [1978] describes many other problems with
using descriptive data for identity. The solution calls for
built-in support for identity in the language which is
independent of its external descriptive data, so that the
system can provide a strong notion of identity in both the
representation and temporal dimensions. Strong support
is provided in the representation dimension because
identity is built-in. Strong support is provided in the
temporal dimension because identity is preserved between
transactions, regardless of changes in data or structure.
RM/F and GEM provide built-in identity for some
persistent objects. These languages are not fully
object-oriented because they lack a uniform treatment of
all objects, providing identity only for persistent tuples.
OPAL [Copeland and Maier 1984] provides built-in
identity for all temporary and persistent objects.
Several researchers have argued for a temporal data
model [e.g., Copeland 1980 and 1982, Ben-Zvi 1982,
Clifford and Warren 1983, Katz and Lehman 1984,
Copeland and Maier 1984]. The reason is that most
real-world organizations deal with histories of objects, but
they have little support from existing systems to help
them in modeling and retrieving historical data. Strong
support of identity in the temporal dimension is even
more important for temporal data models, because a
single retrieval may involve multiple historical versions of
a single object. Such support requires the database
system to provide a continuous and consistent notion of
identity throughout the life of each object, independently
of any descriptive data or structure which is user
modifiable. This identity is the common thread that ties
together these historical versions of an object.
Database systems must provide efficient access to
large data. To deal with this, database languages usually
provide the capability to map the user's conceptual
schema onto an internal schema, which describes the way
that data is actually stored [ANSI/X3/SPARC 1975]. An
internal schema may have multiple copies of the
conceptual schema and may further partition the
auzibutes of an object of the conceptual schema. Some
way of relating these multiple copies and attribute
partitions to the same conceptual object is needed. The
object's identity provides a convenient way of doing this.
2.4 The Hybrid Environment
Programming with persistent data has always been
difficult because programming language environments
and database systems are each designed within different
cultures. They are usually built on different concepts for
typing, computation and identity. Typing systems in
programming languages typically include arrays, lists and
atomic types, while typing systems in database languages
typically include sets, records and atomic types.
Computational models in programming languages are
typically rich in manipulation capability, while
computational models in database languages typically
include only search and simple update capability. The
notion of identity in programming languages is typically
weaker than that of database systems.
September1966 OOPSLA'86 Proceedings
The interfaces between programming and database
languages are usually crude because of these differing
concepts and because they are usually designed as an
afterthought. This causes what some have called an
"impedance mismatch" [Copeland and Maier 1984],
because much of the recta information (e.g., structures
and operations) in either system is reflected back at the
interface rather than passing through it. This meta
information must be defined redundantly in both
languages. Also, transformations must be defined
whenever data or operations need to pass through the
interface.
There is a growing trend to merge programming and
database languages into a hybrid environment which
includes a language with a unified typing and
computation. Some researchers have approached the
problem by making programming language data types
persistent. Some examples of this approach are PS-algol
[Atkinson et al. 1983], Amber [Cardelli 19844 Poly
[Matthews 1985] and Galileo [Albano et al. 1985]. These
languages extend the file system to support the same
types as in the language and provide type checking when
file objects are imported into a program. Others have
approached the problem by combining programming and
database language data types and database transactions.
Some examples of this are PASCAIJR [Schmidt 1977]
which combines PASCAL with relational data types,
PLAIN [Wasserman 1979] and RIGEL [Rowe and Shoens
1979] each of which combines a new programming
language with relational data types, and OPAL [Copeland
and Maier 1984] which combines Smalltaik-80 and a set
data type with predicate calculus.
Regardless of how one approaches this merging of
programming and database capability, the end result
should be a language with a uniform treatment of types,
computation and identity. Data instances of any type
should be capable of being either temporary or persistent.
Any computation should apply uniformly to either
temporary or permanent data, although computations
which cause state changes of shared persistent data
should be enveloped by a transaction. All types should
employ the same notion of identity.
3 An Object Model
This section provides an object model which
incorporates object identity. Much of this model is
similar to the Smalltalk-80 [Goldberg and Robson 1983]
and FAD [Bancilhon et al. 1985] languages. Our purpose
is not to present a complete language, but rather to
demonstrate how the strong notion of identity in the
representation dimension (i.e., built-in) can be
incorporated into an object model. We concentrate on the
definition of object structures and those operators which
manipulate identity. Although this model includes only
atomic and two structured types, its generalization to
other structured types is straightforward.
409
3.1 Object Structure
The object structure is very similar to the object
structure of FAD [Bancilhon et al. 1985]. We assume we
are given a set of attribute names A, a set of identifiers I,
a collection of base atomic types.
An object 0 is a triple (identO~er, type, value) where
a) The identifier is in I. The identifier of an object O
is denoted O.identity.
b) The type is in {atom, set, tupic}. We provide only
single-level typing for simplicity. A more complete
typing system would be desirable for a full language
(for example, a set of tuples whose attribute values
are typed). .
c) The value is one of the following:
1) If the object is of the type atom, then the value
is an element of a user-defined domain of atoms,
each of which has no subparts.
2) If the object is of the type set, then the value is a
set of distinct identifiers from I.
3) If the object is of the type topic, then the value
is of the form
[AI:II, A2:12..... An:In], where the Ai's are distinct
attribute names, and the lJ's are distinct identifiers
from I. II is the value taken by the object O on
attribute Ai and is denoted O.AI.
Note that this model allows us to have objects of
arbitrary nestings and graphical structure. For example,
we can have nested relations [Jaeske and Schek 1982] and
nested tuples [Zaniolo 1985].
Objects can be represented graphically. We represent
an atomic object by a node labeled by its value, a tuple
object O = tAI:O1 . . . . . An:On] by a node labeled by its
identifier such that there is an arc labeled A/which goes
from O to Oi, and a set O = {O1. . . . . O~} by a node
labeled by its identifier such that there is an unlabeled arc
going from O to every Ol. As an example, suppose we
have a database which consists of employees and
students, where each has a name, consisting of first name
and last name, and an age. Then an instance of the
database could be represented as in Figure 2.
emp • ~ e n t
John D~ smith Mark Smith
FIGURE 2: Object Model Example
410 OOPSLA~6 Proceedings
An Object System is a set of objects. An object system
is consistent if
(a) No two distinct objects have the same
identifiers (unique identifier assumption). In other
words, the identifier functionally determines the
type and the value of the object.
Co) For each identifier present in the system there
is an object with this identifier (no dangling
identifier assumption).
All object systems will be assumed consistent throughout
this paper. This definition of objects allows a
directed-graph structure. An object can belong to
multiple objects through set membership or a ~ i b u t e
assignment without being replicated and without being
owned by any object.
3.2 Operators Wlth Object Identity
In the previous section we defined object structure
with identity. In this section, we define several operators
which compare or manipulate objects with identity, and
give an informal semantics for each operator.
Definition: identity predicate (identical)
Given two objects, O1 and 02 the predicate
identical(O1, 02) will return true if Ol and 02 are the
same. Therefore, identical(Of, 02) is true if Or.identity
- O2.identity.
Definition: shallow equality predicate (shallow-equal)
Two objects are shallow--equal if their values are
identical. Note that this definition is not recursive, i.e.,
two set objects whose elements have pairwise equal values
are not necessarily shallow--equal or two tuples whose
attributes have pairwise equal values are not necessarily
shallow-equal.
Definition: deep equality predicate (deep--equal)
Object deep equality is defined as follows:
(a) Two atomic objects are deep-equal if their
values are the same (note that deep-equal and
shallow-equal are the same for atomic objects).
Co) Two set objects are deep-equal if the they have
the same cardinality and the elements in their
values are pairwise deep--equal.
(c) Two tuple objects are deep-equal if the value
they take on the same attributes are deep-equal.
This shows that we have three flavors of "equality":
(I) Identical, which checks if the two objects are
the same object.
(2) Shallow, which goes 1 level deep, comparing
values of the components of the object.
(3) Deep, which recursively traverses the objects,
comparing equality of corresponding components.
Each is an equivalence relation on objects: (3) refines (2)
and (2) refines (1). Therefore, two identical objects are
always shallow-equal and deep-equal. Furthermore, two
shallow-equal objects are always deep--equal.
Sel~ember1986
 Next, we discuss two kinds of operators which are
used to update tuple and set objects. Atomic objects are
not updatable.
Definition: axsigning an object to an attribute of a tuple
(assign)
To assign an object to an attribute of a tuple we use:
assign(<tuple object>, <attribute name>, <object>).
The effect of this operator is to assign the <object> to
<tuple object>.<attribute name>. Por example, if X =
[name:Ol, age:O2], then assign(X, salary, 03) will yield
X ,. [name:Ol, age:O2, salary:O3]. The identities of X,
O1, 02 and 03 are not changed. If X.salary was defined
before the assignment, 03 will replace the old X.salary.
Definition: adding an element to a set (add-elemenO
The second operation on sets adds an element to a
set. Therefore,
add-element(<set object>, <object>)
will add <object> as an element of <set object>. The set
or any of its existing elements are not affected. Note that
if the object already exists in the set, the effect of the
add-element update operator is null. However, if the set
already contains an object which is either shallow, equal
or deep-equal to the object to be added (but not identical
to it), the object will still be added to the set. Below, we
shall introduce an operator which eliminates duplicates
based on values.
Definition: removing an element from a set (remove-element)
The third operator on sets removes an element from a
set. Therefore,
remove-element(<set object>, <object>)
will remove <object> from <set object>, if the object is
there.
Definition: value elimination from a set (value-eliminate)
We already alluded to the problem of the existence of
value based duplicates in a set. This problem becomes
important if we want to generate a final result showing
only the content (i.e., the values) of the set object without
any duplicates. If an operation is interested in only
manipulating unique values (e.g., count the different
colors of parts), without value elimination we might have
redundant information accessed and manipulated.
Therefore, the fourth operator on sets performs value
based duplicate elimination:
value-eliminate(<set object>).
If O is a set object, value-eliminate(O) will create a new
set object whose elements are new objects and whose
values are the same as in O but without duplicate values.
That is, there will be no two distinct elements Ol and 02
in value-eliminate(O) that are deep-equal. The existence
of identity and value elimination allows the option of
either objects or values to be manipulated.
September1986 OOPSLA ~6 Proceedings
Def'mitlon: merging two objects into one (merge)
Another operator which is useful for systems that
support object identity merges two objects and makes
them a single object. In other words, if we realize that
two similarly structured objects are really the same we
could have
merge(Ol, O2),
which will merge the two objects and henceforth they will
be one and the same object. Note that this is an updating
operation. The semantics and support of this operation
could be tricky and expensive. The simplest approach is
to require the two objects to have the same type and be
deep-equal. Then all that we need is to ensure all the
references to the old objects and their sub-components
now refer to the merged object and its sub-components.
However, it is possible to make merging more
sophisticated and provide support for merging differently
structured objects. This is a very useful concept in
statistical databases called record-linking [Wrigley 1973,
Howe and Lindsay 1981], where an attempt is made to
merge information which was gathered by different
sources and which contain different sorts of information
about the same objects.
Finally, similar to the different flavors of equality,
there are two flavors of object copying, called
shallow-copy and deep-copy.
Definition: shallow copying (shallow-copy)
The shallow-copy operator will copy its first
argument into the second, such that the resulting object
will be shallow-equal to the first and the two objects will
have different identity. Therefore,
shallow-copy(Ol, 02)
will generate a new object 02 such that O2.identity is not
equal to Ol.identity but shallow-equal(O2, Or) is true.
Definition: deep copying (deep-copy)
The deep-copy operator will copy its first argument
into the second, such that the resulting object will be
deep-equal to the first and the two objects will have
different identity. Therefore,
deep-copy(Ol, 02)
will generate a new object 02, with all new sub-parts,
such that, if Ot is a set or a tuple, 02 is not shallow-equal
to O1, but 02 is deep-equal to O1. Deep-copy should
also preserve co-referencing.
4 Implementation Techniques
There have been several techniques for implementing
object identity both in databases and in programming
languages. In this section, we first provide a taxonomy of
identity implementation techniques. We draw our
examples from programming languages, distributed file
systems and database management systems. Then, we
describe how the object system in Section 3 can be
implemented using surrogates, which is the most powerful
of these techniques.
411
4.1 Implementation Taxonomy
The power of each implementation technique can be
measured by the degree of value, structure and location
independence it provides. Data independence means that
identity is preserved through changes in either data values
or structure. Location independence means that identity
is preserved through movement of objects among physical
locations or address spaces. Both of these are important
when implementing objects with the strong notion of
identity in both the representation and temporal
dimensions as described in Section 2.
Figure 3 describes where these implementation
techniques lie in the two dimensional space provided by
this taxonomy. Some of the details of these techniques
are described below.
address implementation allows only whole pages of
objects, not individual objects, to be moved within one
virtual address space, providing minimal location
independence. However, because objects cannot be
moved between address spaces, object sharing among
multiple programs is limited. Both real physical address
and virtual address implementations provide data
independence, unless such modifications cause the.object
to be moved within the address space due to size
differences.
Identity Through Indirection
In Smalltalk-80 [Ooldberg and Robson 1983], an oop
(object-oriented pointer) is used to implement identity.
An oop is an entry in an object table. Therefore,
identities are implemented through a level of indirection.

DATA
INDEPENDENCE

real virtual indirect indirect structured surrogate

fully physical physical virtual for each
independent address address address address identifier object

value
independent surrogate
somewhat for each
structure tuple
dependent

value
independent tople
structure identifier
dependent

value and identifier

structure key
dependent

I I I. I I ! LOCATION
cannot move move move move . fully. "~ INDEPENDENCE
move page object object object inoepenoent
within within within within
one one one one
virtual physical virtual disk or
address address address server
space space space

FIGURE 3: Implementation Taxonomy

Identity Through Physical Address

Perhaps the simplest implementation of the identity of
an object is the physical address of the object. This
physical address could be the real or the virtual address
of the object (if the object system is operating in a virtual
memory environment). For example, in PASCAL the
"identity" of a record (i.e., the pointer to the record) is
implemented through a virtual heap address. Physical
address implementation does not permit an object to be
moved, so that there is no location independence. Virtual
In LOOM [Kaehler and Krasner 1983], it is shown that
this scheme could be used to support secondary-storage
resident objects, providing support for a much larger
number of objects. Indirect physical or virtual address
implementations allow individual objects to be moved
within one address space, providing stronger location
independence than direct address implementation but not
allowing sharing of objects among multiple programs.
Indirect address implementations provide full data
independence.

412 OOPSLA '86 Proceedings .Seplember1986

Identity Through Structured Identifier
In some distributed systems, such as the Cambridge
File Server [Dion 1980] and the LOCUS system [Popek et
al. 1981], the identifiers of files (the objects of the
systems) are structured, where pan of the structure
captures an aspect of the location of the object, such as a
disk or server. For example, in LOCUS part of the
identifier of a file identifies a (logical) volume where the
file is located. Structured identifiers provide full data
independence. Structured identifiers allow individual
objects to be moved within one disk or server, although
movement among multiple address spaces is possible so
that objects can be shared among multiple programs.
One reason why movement of object is desirable is
due to the load balancing in a distributed systems. In
other words, if a server contains many "hot" objects, the
overall performance of the distributed system will
improve if some of the hot objects are moved to another
site (e.g., volume or site).
Identity Through Identifier Keys
The main approach for supporting identity in
database management systems is by direct
implementation of user-supplied identifier keys. The
tuples are ordered (in most cases sorted) on the identifier
key and an auxiliary structure (e.g., a B-tree) is
constructed on top of the set of tuples to provide fast
access to objects retrieved through their identifier keys.
Identifier key implementations provide full location
independence. They do not provide value independence
because they consist of values. They do not provide
structure independence because they are unique only
within a single relation (e.g., a relation may be
restructured into two relations) and they are applied only
to tuples and not to attributes (e.g., an attribute object
may be expanded into a. tuple on its own).
Identity Through Tuple Identifiers
In some systems, such as System R [Astrahan et al.
1976], INGRES [Stonebraker et al. 1976] and WiSS
[Chou et al. 1985], internal tuple identifiers are
introduced in the internal layer to simplify the interfaces
of the DBMS layering scheme and to implement the
concurrency control/recovery module of the DBMS. These
tuple identifiers should not be confused with the
implementation of identity, since they do not directly
correspond to any conceptual notion of identity. Tuple
identifiers can, however, be used to implement identity.
They are system-generated identifiers which are unique
for all tuples within a single relation and have no
relationship to physical location. Tuple identifiers provide
full location independence. They also provide full value
independence. They do not provide full structure
independence since they are unique only within a single
relation and they are applied only to tuples and not to
attributes.
Identity Through Surrogates
The most powerful technique for supporting identity
is through surrogates [Abrial 1974, Hall et al. 1976, Kent
1978, Codd 1979]. Surrogates are system-generated,
September1986 OOPSLA '86 Proceedings
globally unique identifiers,completely independent of any
physical location. Leach et al. [1982] argue for the use of
surrogates in distributed systems. The arguments of
location independence presented therein are also valid for
distributed database management systems. Surrogates
provide full location independence. If surrogates are
associated only with some objects, such as tuples in RM/T
[Codd 1979] and G E M [Tsur and Zaniolo 1984], then
they provide value independence but not full structure
independence. If surrogates are associated with every
object as in OPAL [Maier et al. 1985], then they provide
full data independence.
4.2 Implementing The Object Model With Surrogates
This section provides a more detailed description of
how to realize the object model in Section 3 using
surrogates.
Each object of any type is associated with a globally
unique surrogate at the instant it is instantiated. This
surrogate is used to internally represent the identity of its
object throughout the lifetime of the object. Leach et al.
[1982] discusses several implementation issues involved
in the non-trivial task of generating globally unique
surrogates in a distributed environment.
There are several reasons why the physical
description of a conceptual object may not be stored in a
single location. One reason is that some of the parts of
an object may be shared by other objects due to the graph
structure of the object model. An object referenced by
multiple objects cannot be physically stored with each of
its referencing objects without uncontrolled replication. A
second reason is that controlled replication may be used
to facilitate data recovery. These replicates must be
physically stored on separate media for maximum
recoverability. A third reason is that the parts of an
object may be physically partitioned based on frequency
of use together to improve performance for disk-resident
data [Hoffer 1975]. A fourth reason pertaining to support
of a temporal data model is that the current version may
be kept separately from past versions of objects, so that
the speed of access to current data is not reduced. For all
of these, an object's surrogate provides a convenient way
to relate these separately stored replicates or parts of the
single conceptual object.
Testing for identity (i.e., Ol.identity = O2.identity) is
required to support identity and shallow-equal predicates.
This is accomplished by testing surrogate equality (i.e.,
Or.surrogate = O2.surrogate).
The remove-element operator requires checking for
dangling identifiers to insure consistency of the object
system. That is, there should not be any references to an
object that does not exist. This could be implemented by
searching for dangling surrogates each time such an
update is made. This is similar to the technique used in
databases which allow foreign identifier key declaration
with referential integrity enforcement.
The assign operator may cause the last reference to
an object to disappear, so that it is no longer accessible
and its storage can be freed. This could be implemented
by keeping a reference count for each object (i.e., the
413
number of references to an object), which is updated each
time a reference is added or removed. When the
reference count of an object goes to zero, garbage
collection is invoked. This is important for temporary
data and is used in the Smalltalk-80 system [Goldberg
and Robson 1983].
The merge operator causes two objects to become
one. This could be implemented by maintaining an
equivalence relationship between the two surrogates.
To support systems that form a hybrid of
programming languages and database systems, it is
important to maintain a consistent and continuous notion
of identity throughout the lifetime of an object. Let us
consider an object that is first created as a temporary and
later made persistent. Although the strong notion of
identity in both the representation and temporal
dimensions is most important to persistent objects, this
ability to change status means that the same
implementation representation of identity should apply to
both temporary and persistent objects.
5 Summary
Most programming and database languages mix the
concepts of addressability and identity, using variable
names as the only way to distinguish temporary objects.
Most database languages mix the concepts of data value
and identity, using identifier keys as the only way to
distinguish persistent objects. Both of these concepts
compromise identity. Object-oriented languages
distinguish these concepts, providing a stronger notion of
identity which is independent of how an object is accessed
or described with data values.
We discussed the importance of identity in both
programming and database languages as well as
languages which combine the power of both these
disciplines. Strong identity involves two dimensions,
representation and temporal. The representation
dimension distinguishes languages based on whether they
represent the identity of an object by its value, by a
user-defined name, or built into the language. The
temporal dimension distinguishes languages based on
whether they preserve their representation of identity
within a single program or transaction, between
transactions, or between structural reorganizations. Strong
identity in the representation dimension is important for
both temporary and persistent objects. Strong identity in
the temporal dimension is important for persistent
objects. For hybrid languages which merge programming
and database functionality, a strong identity in both
dimensions is important due to the need for a uniform
treatment of all objects, because their status may change
between temporary and persistent.
We defined a data model, including structures and
operations, which supports complex objects with strong
identity. Although structures included only atomic types
and two structured types (i.e., set and tuple), its
generalization to other structured types is straight
forward. The operators serve as the building blocks of a
data manipulation language based on this object model
with identity.
414 OOPSLA~ Procxdings
We compared different implementation techniques
for identity using a taxonomy which is based on data and
location independence. Value and structure independence
means that identity is preserved through changes in either
data values or structure. Location independence means
that identity is preserved through movement of objects
among physical locations or address spaces. The most
robust of these techniques is surrogates, which provides
full independence in both dimensions. We described how
the object model could be implemented using surrogates.
Acknowledgments
Thanks to David Maier of OGC for his many
suggestions concerning both the content and presentation
of this paper.
References
J.R. Abrial, "Data Semantics," in Data Base
Management, J.W. Kiimbie and K.L. Koffeman, eds.,
North-Holland Publishing Co., New York (1974).
A. Albano, G. Ghelli and R. Orsini, "The Implementation
Of Galileo's Values Persistence," Proceedings O f The
Appin Workshop on Persistence And Data Types,
University Of Glasgow (August 1985).
M.M. Astrahan, M.W. Biasgen, D.D. Chamberlin, K.P.
Eswaran, J.N. Gray, P.P. Griffiths, W.F. King, R.A. Lorie,
P.R. McJones, J.W. MChl, G.R. Putzolu, I.L. Traiger,
B.W. Wade and V. Watson, "System R: Relational
Approach To Database Management," Transactions On
Database Systems, ACM, Vol. 1, No. 2 (June 1976).
ANSI/X3/SPARC, Study Group On Data Base
Management Systems Interim Report 75-02-08, FDT
Bulletin, Vol. 7, No. 2 (February 1975).
M.P. Atkinson, P.J. Bailey, W.P. Cockshott, K.J.
Chisholm and R. Morrison, "An Approach To Persistent
Programming," Computer Journal, Vol. 26, No. 4 (1983).
F. Bancilhon, S. Khosbafian and P. Valduriez, "FAD, A
Database Machine Language, Formal Description,"
personal cormnunications (1985).
J. Ben-Zvi, "The Time Relational ~vlodel," Ph.D.
Dissertation, UCLA (1982).
L. Cardeili, "Amber," AT&T Bell Labs Technical
Memorandum 11271-840924--10TM (1984).
D.D. Chamberlin and R.F. Boyce, "SEQUEL: A
Structured English Query Language," Proceedings of the
SIOMOD Workshop On Data Description, Access And
Control, ACM, Ann Arbor (May 1974).
September1966
H.T. Chou, D.J. DeWitt, R. Katz, and A. Klug, "Design
And Implementation of The Wisconsin Storage System,"
Software Practice And Experience, Vol. 15, No. 10
(October 1985).
J. Clifford and D.S. Warren, "Formal Semantics For
Time In Databases," Transactions On Database Systems,
ACM, Vol. 8, No. 2 (June 1983).
E. F. Codd, "A Relational Model Of Data For Large
Shared Data Banks," Communications of the ACM, Vol.
13, No. 6 (June 1970).
E. F. Codd, "Further Normalization Of The Data Base
Relational Model," in Data Base Systems, Courant
Institute Computer Science Symposia 6, R. Rustin (ed.),
Prentice-Hall, Inc., Englewood Cliffs, New Jersey (Nlay
1971).
E. F. Codd, "Extending The Database Relational Model
To Capture More Meaning," Transactions On Database
Systems, ACM, Vol. 4, No. 4 (December 1979).
A. Colmerauer, "Les Grammaires De Metamorphose,"
Groupe d'Intelligence Artificielle, Marseille-Luminy
(November 1975).
G.P. Copeland, "What If Mass Storage Were Free?,"
Proceedings Of The Fifth Workshop On Computer
Architecture For Non-Numeric Processing, ACM, Pacific
Grove, California (March 1980); a revised version
appears in Computer, II~.R Computer Society, Vol. 15,
No. 7 (July 1982).
G.P. Copeland and D. Maier, "Making Smalltalk A
Database System," Proceedings of the SIGMOD
Conference, ACM, Boston (June 1984).
J. Dion, "The Cambridge File Server," Operating Systems
Review, ACM SIGOPS, Vol. 14, No. 4 (October 1980).
A. Goldberg and D. Robson, Smalltalk-80: The Language
And Its Implementation, Addison-Wesley Publishing Co.,
Reading, Massachusetts (1983).
P.A.V. Hall, J. Owlett and S.J.P. Todd, "Relations And
Entities," In Modeling In Data Base Management
Systems, G.M. Nijssen, ed., North-Holland Publishing
Co., New York (1976).
J.A. Hoffer, "A Clustering Approach To The Generation
Of Subfiles For The Design Of A Computer Database,"
Ph.D. dissertation,Cornell University (January 1975).
G.R. Howe and J. Lindsay, "A Generalized Iterative
Record Linkage Computer System For Use In Medical
Follow-up Studies," Computers And Biomedical
Research, Vol. 14 (1981).
September1986 OOPSLA ~6 Proceedings
O. Jaeske and H. Schek, "Remarks On The Algebra Of
Non First Normal Form Relations," Proceedings of the
Symposium On Principles Of Database Systems, ACM
SIGACT-SIGMOD, Los Angeles (March 1982).
T. Kaehler and G. Krasner, "LOOM--Large
Object-Oriented Memory For Smalltalk-80 Systems," in
Smalltalk-80: Bits Of History, Words Of Advice,
Addison-Wesley Publishing Co., Reading, Mass. (1983).
R.H. Katz and T.J. Lehman, "Database Support For
Versions And Alternatives Of Large Design Files,"
Transactions On Software Engineering, IP.I~. Vol.
SE--10, No. 2 (March 1984).
W. Kent, Data And Reality, North-Holland Publishing
Co., New York (1978).
W. Kent, "Consequences Of Assuming A Universal
Relation," Transactions On Database Systems, ACM, Vol.
6, No. 4 (December 1981).
P.J. Leach, B.L. Stumpf, J,A. Hamilton and P.H. Levine,
"UIDS As Internal Names In A Distributed File System,"
Proceedings of the First Symposium On Principles Of
Distributed Computing, ACM, Ottawa (August 1982).
D. Maier, J.D. Ullman and M.Y. Vardi, "On The
Foundations Of The Universal Relation Model,"
Transactions On Database Systems, ACIVl, Vol. 9, No. 2
(June 1984).
D.C.J. Matthews, "An Overview Of The Poly
Programming Language," Proceedings Of The Appin
Workshop on Persistence And Data Types, University Of
Glasgow (August 1985).
D. Maier, A. Otis and A. Purdy, "Object-Oriented
Database Development At Servio Logic," Database
Engineering, l l ~ , Vol. 8, No. 4 (December 1985).
G. Popek, B. Walker, J. Chow, D. Edwards, C. Kline, G.
Rudisin and G. Thiel, "LOCUS: A Network Transparent,
High ReliabilityDistributed System," Proceedings of the
Eight Symposium On Operating Systems Principles,
(December 1981).
D.M. Ritchie and K. Thompson, "The Unix Time-Sharing
System," Communications Of The ACM, Vol. 17, No. 7
(July 1974).
L. Rowe and K. Shoens, "Data Abstraction, Views And
Updates In RIGEL," Proceedings of the S I G M O D
Conference, ACM, Boston (May 1979).
J.H. Saltzer, "Naming And Binding Of Objects," in
Lecture Notes In Computer Science, Goos and Hartman,
eds., Springer-Verlag, (1978~.
415
J.W. Schmidt, "Some High Level Language Constructs
For Data Type Relation," Transactions On Database
Systems, ACM, Vol. 2, 14o. 3 (September 1977).

J.M. Smith and D.C.P. Smith, "Principles Of Database

Conceptual Design," Proceedings Of The NYU
Symposium On Database Design, New York (May 1978).

G.H. Sockut, "A Framework For Logical-Level Changes

Within Database Systems," Computer, ~ E Computer
Society, Vol. 18, No. 5 (May 1985).

M. Stonebraker, E. Wong and P. Kreps, "The Design And

Implementation Of INGRES," Transactions On Database
Systems, ACM, Vol. 1, No. 3 (September 1976).

S. Tsur and C. Zaniolo, "An Implementation Of

GEM--Supporting A Semantic Data Model On A
Relational Back-End," Proceedings of the SIGMOD
Conference, ACM, Boston (June 1984).

A.I. Wasserman, "The Data Management Facilities Of

PLAIN," Proceedings of the SIGMOD Conference, ACM,
Boston (May 1979) .

N. Wirth, "The Programming Language PASCAL," Acta

lnformatica 1, Vol. 1 (May 1971).

E.A. Wrigley (ed.), Identifying People In The Past,

Edward Arnold, London (1973).

C. Zaniolo, "The Database Language GEM," Proceedings

of the SIGMOD Conference, ACM, San Jose (May 1983).

C. Zaniolo, "The Representation And Deductive Retrieva'

Of Complex Objects," Proceedings of the International
Conference on Very Large Data Bases, Stockholm
(August 1985).

M.M. Zloof, "Query By Example," Proceedings of the

NCC, AFIPS Press, Montvale, N.J. (May 1975).

416 OOPSI..A'86 ~ i r t g 8 ~ 1966