Object Modeling

Object modeling describes systems as built out of objects:
programming abstractions that have identity, behavior, and
state. Objects are an abstraction beyond abstract data types
(ADTs), where data and variables are merged into a single
unifying concept. As such they object modeling includes many
other concepts: abstraction, similarity, encapsulation,
inheritance, modularity, and so on. See references for
Object-Oriented design ([Booch 95], [Rumbaug+BPEL 91], [Kilov+R
94]) for more information on the concepts of object modeling.

For this paper, we will be concerned with the basic object
concepts of identity, behavior, state, and encapsulation. We
will also need some higher level concepts of type, association,
class, and inheritance. Each of these will be defined below.

Basic Concepts

Identity

Objects have identity, which distinguishes them from
all other objects. This is the crucial step for describing how
objects are different from ADTs. When an object is created it is
distinguishable from all other objects whether its state (or
"value") happens to be equal

State

Because an object can be distinguished independently of its
"value", it has a state: the current value associated
with this identity. Objects can have a single state through
their whole life (which would make them degenerately like ADTs)
or can go through many state transitions. Because objects are
encapsulated, the state is an abstraction and is only visible by
examining the behavior of the object.

Behavior

Objects provide an abstraction that clients can interact
with. The behavior of an object is the collection of
provided interactions (called methods or operations and,
collectively, an interface) and the response to these method
calls (or "messages"). All interactions with an object must be
through its interface and all knowledge about an object is from
its behavior (returned values or side effects) to the interface
interaction.

Encapsulation

Encapsulation provides an abstraction and prevents
external parties from seeing the implementation details for that
abstraction. For objects, clients can interact with the public
behavior of the object (and by so doing identify the state of an
object) but they can not see how the behavior and the state are
implemented.

Higher-level Concepts

Type

A type is the specification of an interface that
objects will support. An object implements a (is a) type if it
provides the interface described by the type. All object of the
same type can be interacted with through the same interface. An
object can implement multiple types at the same time.

Associations

Types can be associated with other types, which
specifies that the objects of one type can be linked to
objects of the other type. Having a link provides the ability to
traverse from one object to the other objects involved in the
link.

Class

One approach for implementing objects is to have a class,
which defines the implementation for multiple objects. A class
defines what types the objects will implement, how to perform
the behavior required for the interface and how to remember
state information. Each object will then only need to remember
its individual state. Although using classes is by far the most
common object approach, it is not the only approach (using
prototypes is another approach) and is really peripheral to the
core concepts of object-oriented modeling.

Inheritance

Inheritance can apply to types or to classes. When
applied to types, inheritance specifies that object of ‘Type B’
that inherits from ‘Type A’ can be used just like an object of
‘Type A’. Type B is said to conform to Type A and
all objects that are Type Bs are also Type As.

When applied to Classes, inheritance specifies that a class
uses the implementation of another class with possible
overriding modification. This frequently implies type
inheritance also but that is not always the case.

Summary

Object models are different from other modeling techniques
because they have merged the concept of variables and abstract
data types into an abstract variable type: an object. Objects
have identity, state, and behavior and object models are built
out of systems of these objects. To make object modeling easier,
there are concepts of type, inheritance, association, and
possibly class. Although object modeling is only a small step
from data type oriented programming, it produces a significantly
different feel and structure for programs. Object modeling’s
focus on identity and behavior is completely different from the
relational model’s focus on information.

Relational Modeling

Relational modeling describes a system’s information as truth
statements. We will tell the database truth axioms about the
world and the database will remember these truths and even be
able to prove other "new" (derived) truths from its model and
our axioms. We must also have a way to be sure we understand
what we are telling the database and what the database is
telling us: we must be able to translate between the human
knowledge and the database model. All of this is accomplished in
the relational model through well-defined terms like relation,
tuple, domain, and database.

Relational Terminology

The following describes the concepts to the relational model.
Most of these are identical to the definitions given in [Date
95], but I draw a finer distinction between certain terms
(specifically relation and relation value).

Relation

A relation is a truth predicate. It defines what
attributes are involved in the predicate and what the meaning of
the predicate is. Frequently the meaning of the relation is not
represented explicitly, but this is a very significant source
for human error in using the database system. An example of a
relation is:

Person: {SSN#, Name, City} There exists
a person with social security number SSN#, who has the name
Name, and lives in a city named City.

Attribute

An attribute identifies a name that participates in
the relation and specifies the domain from which values of the
attribute must come. In the above relation, Name is an
attribute defined over the String domain. The above relation
should explicitly identify the domains for each attribute:

Person: {SSN# : SSN, Name :
String, City : CityName} There exists a person
with social security number SSN#, who has the name Name, and
lives in a city named City.

Domain

A domain is simply a data type. It specifies a data
abstraction: the possible values for the data and the operations
available on the data. For example, a String can have zero or
more characters in it, and has operations for comparing strings,
concatenating string, and creating strings.

Tuple

A tuple is a truth statement in the context of a
relation. A tuple has attribute values which match the required
attributes in the relation and that state the condition that is
known to be true. An example of a tuple is:

Tuples are values and two tuples are identical if their
relation and attribute values are equal. The ordering of
attribute values is immaterial.

Attribute Value

An attribute value is the value for an attribute in a
particular tuple. An attribute value must come from the domain
that the attribute specifies.

Relation Value

A relation value is composed of a relation (the
heading) and a set of tuples (the body). All the tuples must
have the same relation as the heading and, because they are in a
set, the tuples are unordered and have no duplicates. A relation
value could be shown as a set of tuples:

It is more common and concise to show a relation value as a
table.

: Person

In this representation, the heading is specified by the ":
Person", the attributes of the heading are ordered (for
presentation only) by the column headings, and the rows define
what tuples exist.

All ordering within the table is artificial and meaningless.
The following is a different presentation of the identical
relation value.

: Person

Relation Variable

A relation variable holds onto a single relation value
at any point in time, but can change value at any point in time.
Relation variables are typed to a particular relation, so they
will always hold relation values that have a heading with that
relation. A relation variable would look like:

People : Person

This shows the variable name "People" and the variable
relation type "Person".

Using the tabular structure from above, we can show a
relation variable and its current value.

People : Person

Database

A database is a collection of relation variables. It
describes the complete state of an information model, can change
state (by changing the relation variables), and can answer
questions about its particular state.

Base Relation Values

A base relation value has been explicitly told to the
database at some point in time. The above People relation could
be such a base relation, in which case we explicitly told the
database that Lino Buchanan and Art Larrson are people.

Derived Relation Values

Derived relation values are calculated from other
relation values known to the database. For our example data, the
number of people located in each city is:

: PersonCount

Which can be derived from the information in the "People"
relation variable.

Derived relation values are most commonly the result of
relational expressions and queries. They are also frequently
permanently remembered (and recalculated) through views:
derived relation variables.

Coupling between relations, variables, and values

Relations, variables, and values are more coupled than they
may first appear to be. Because a relation includes a meaning, a
relation variable must have the same meaning as the relation. So
defining a variable "HappyPeople : Person" does not make sense
because the predicate for ‘Person’ does not describe happiness.
What we are really saying is we have a new relation
‘HappyPerson’ which is almost identical to person but has a
slightly extended meaning:

HappyPerson: {SSN#, Name, City} There exists a person with social security number SSN#,
who has the name Name, and lives in a city named City, and that person is happy.

or using a more concise definition

HappyPerson extends Person: And that person is happy.

New anonymous relations are produced for all derived values
(except the identity transformation). This can cause confusions
because the anonymous relations are not well defined and
different users of the database may have different
interpretations.

Common Database Terminology

The previous section defined the correct relational model
terminology, but databases have a longer history with different
terms that are now overloaded to apply in the relational
context. The approximate equivalencies between these terms are
given in the following table.

Summary

Relational modeling works in terms of predicates, truth
axioms, and derivable truth statements. Relations define the
possible truth statements, tuples describe the current known
truths, relation values collect truth statements together,
relation variables remember values, and relation expressions can
derive new values.

The relational model is very different from the object model.
In many ways the difference is helpful because in most areas
object and relational modeling are orthogonal: their concerns
are completely different. The next chapter introduces how to
integrate the two approaches.

Objects integrated into the
Relational Model

Object modeling describes a system through objects that have
identity, behavior, and encapsulated state. Relational models
describe a system by information. How can a relational model
support object modeling? Of the primary object-modeling
properties, relational modeling seems to have no way of
representing any of them directly. Tuples have neither identity
nor encapsulation. Tuple attribute values are encapsulated but
are pure values, so they have neither identity nor state. This
is what is frequently called an impedance-mismatch between
object approaches and relational databases.

Fortunately this is not really the case. Predicate logic is
quite good at describing the state of the world (or of a model
of the world), so relational databases must be quite good at
describing the state of an object model. To see how easily they
can model an object model’s state we will first expand the
relational model slightly.

Objects as Tuple Attribute
Values

What if we allowed Objects (with identity and state) to be
tuple attribute values?

Instead of simply having a social security number (or even a complex value like a graphic image or a rectangle) as a tuple’s attribute value, we can have a ‘Person’ as a tuple’s attribute value. This would allow us to have a predicate "This person is known to be the parent of this person" instead of saying, "The person with this SSN is known to be the parent of the person with this SSN". We don’t care about a person’s SSN (which might change) or any of the other attributes of a person: we have direct representations of the people themselves.

This merger provides much flexibility. Anywhere we used to
have a primitive or abstract data type we can now have an
object. For this to fit with the relational model we will
enhance Domains to be able to take their "values" from a pool of
existing objects or to be able to create a new object when
asked.

Redundancy and Normalization

Now that we have integrated the relational model and the
object model we have the problem "which do we ask?" Do I ask
‘Person#1’ for its child (object approach) or do I ask the
Parenthood relation for the children of ‘Person#1’ (the
relational approach)? Presumably I can ask both that question,
but then how do we make sure changes made to one or the other
place are synchronized? We clearly have a severe redundancy
(denormalization) problem between objects with attributes and
the tuples in relations.

This problem is especially obvious for the basic attribute
tables (or Entity table in ER modeling) where every row lists
the attributes of an object. Do we ask the object to change its
attribute or do we change a row in the table?

Because this is a relational model, the relational features
should take precedence: We only want to extend the relational
model well enough so we can easily represent objects in it.
Because the relational model has a complete approach for
changing the state of the database we should not add a second
one. So, we do not change the state of an object through the
methods of an object, but must instead modify the appropriate
relation variables (by adding, removing, or replacing/changing
tuples) to cause the desired changes.

Object Attributes
as Views

Should we allow an object to answer a question about its
attributes? That would be convenient. Instead of having to look
up in the Parenthood table for parents and the Person table for
basic attributes we could instead ask Person#1 for it #firstName
and its #parents. From the relational perspective, the person
object would provide a centralized view on all the tables that
can refer to a person object (i.e. all those tables which have
attributes with Domains that can contain a person).

Assuming the notation <Person#1> represents that actual
person object, then the query

   ‘SELECT Person.SSN FROM Person WHERE Person.Object = <Person#1>’

is equivalent to

   ‘SELECT <Person#1>.SSN’

assuming two things: it is obvious what relation variable
(table) controls the SSN attribute for Person and it is obvious
which attribute in the relation variable we are starting from
(in this case the "Object" attribute). In general this is
unlikely, so we probably would need to explicitly define how the
attributes of an object are a view on the appropriate relation
variables. Something like:

    CREATE DOMAIN PERSON CLASS {
        ssn AS SELECT SSN FROM Person WHERE Object = THIS
        firstName AS SELECT First_Name FROM Person WHERE Object = THIS
        parents AS SELECT Parent FROM Parenthood WHERE Child = THIS
        children AS SELECT Child FROM Parenthood WHERE Parent = THIS
    }   

Where we added the ability to declare a domain which will
have objects with identity as its values (a CLASS), the ability
to declare attributes of that class as views on the database,
and the new keyword THIS to refer to whichever object we are
currently dealing with. Under the covers these views could be
significantly optimized which would give the same performance
advantage for traversals as an object database.

    SELECT children.firstName 
    FROM Person.Object as Parent, Parent.children as children 
    WHERE Parent.firstName = ‘ART’ "

Behavior

To add object behavior requires the ability to specify method
implementations for any given object. Something like:

    CREATE DOMAIN PERSON CLASS {
        setName(newName : String) AS UPDATE ... WHERE Object = THIS
    }   

Discussing behavioral additions is beyond the scope of this
document. So far we have all the capabilities required for an
information modeling and storage system, and added behavior
could be easily added to objects, tables, or the database as a
whole. Effectively these are the three "types" of objects that
could have behavior within our object-relational system.

Inheritance

Type based inheritance can be used as part of integrity
constraints. When we specify that a domain is of a particular
type, this would only allow objects that implement that type or
any conformant subtype to be values in that domain. This allows
similar flexibility and integrity as for a type based
programming language. For example, if we have the two classes:

    CREATE DOMAIN PERSON CLASS {...}
    CREATE DOMAIN EMPLOYEE CLASS EXTENDS PERSON {...}

Then object from either class can be the value of an
attribute of type PERSON. We know that the object will at least
support the PERSON interface although some may additionally
support the EMPLOYEE interface.

Class based inheritance can be used to ease the creation of
classes by having subclasses inherit the attributes and behavior
of the superclass.

What about inheriting among tables? Inheriting among tables
is not inheritance at all; it is just multi-relation compression
and management. Tables are related by having common attributes
(columns and domains) and by having common predicates. Table
"inheritance" (compression) does not affect whether the tables
are related or not, it is just a simple way to implement
possibly related tables. In that sense it is close to class
inheritance, but there is no reason to overload the term
"inheritance" with this distant a meaning.

Summary

This chapter has presented a correct integration of objects
into the relational model. These objects have identity, which is
the foundation for the true integration of object modeling.
Objects can also have attributes and behavior, but these
properties must be in terms of the truth statements and
predicates that are the foundation of the relational model.
Attributes are read from relational expressions and state
modifying behavior must alter the state of relation variables in
the database. The two models are merged and enables us to have
the convenience of object notation with the expressive power of
predicate logic.

Using Current
Relational Databases

The previous section assumed we could modify the
relational model to add features we need for object-relational
mapping. In the long run this may be possible but currently it
is not. Current relational systems do not support objects with
identity as the values of tuple attributes. Most relational
systems do not support anything more than basic data types as
tuple attributes. Have we returned to the impedance mismatch?
No, we already have an approach that is a good integration of
Relational and Object models. We only need to implement it with
current technology.

IdentityKeys:
Relinquishing Objects for ObjectShadows

We can not directly store objects with identity
in current relational databases. Instead we will just store an
IdentityKey as an ObjectShadow: the existence of an
IdentityKey indicates that an Object exists but that the
database can not directly represent the actual object. We only
have the shadow of the object, which is less convenient to work
with but contains as much information.

Distinguishers:
Identifying an Object’s Type

In the above example the type of the
ObjectShadow is obvious. It is always a person for the ID column
and it is always a company for the Company_ID column. What if we
allow the type of a domain to vary over multiple classes? How do
we identify what type of object that shadow is for? We need some
manner to first identify the object’s class and then use the
object’s IdentityKey to identify the object within that class.
We need a more knowledgeable shadow.

We can add this knowledge through a
distinguisher that identifies which class of object the shadow
is for. We first find the class through the distinguisher and
then find the object of that class through the identityKey.

Summary

Working with current relational technology makes
implementing objects in the database much more cumbersome, but
the model is still valid and possible. Instead of having real
objects we have object shadows which indicates the existence of
a particular object. Object shadows can either be simply
IdentityKeys for a single type domain or IdentityKey plus a
distinguisher if the domain could be multiple types. In all
cases the ObjectShadow must be sufficient to uniquely identify
the single true object that should be in its place. If we have
this we have objects.

Conclusion

We now have all the major pieces needed to easily discuss and
analyze object-relational mapping. We have discussed object
modeling and relational modeling. We integrated the two models
into a single object-extended relational model and described how
to implement that model on current relational database systems.
Finally we discussed the issues with client-server object
models.

Not all object-relational mapping products will be able to
support the complete integrated model and all the client-server
capabilities. Some will choose a partial approach or simply not
consider objects at all. The best approach for mapping is up to
each project and product vendor. It will depend on how much of
the integrated model they require, whether they can implement
all the needed functionality, and the time & cost
considerations. The following table identifies and describes
levels of object-relational mapping sophistication from simply
using the relational model up to implementing a full object
mapping as described in this document. At the end is a short
description of the functional capabilities of an active object
server.

Choosing a technique to use from among these levels will
impact performance, cost, scalability, application behavior,
development time, and maintenance. No technique is best at all
these criteria. More sophisticated techniques are not
appropriate for all applications and many applications work just
fine with a purely relational model. Other applications will
grow to a size and complexity that is easier to manage using
object models, and will have to decide which technique and
products will best serve their needs.