OASIS

SERGUEI MANKOVSKII

CA Labs, CA Inc, Thornhill, ON, Canada

Synonyms

Organization for the advancement of structu red

information standards

Definition

OASIS is a non-for-proﬁt consortium aiming at col-

laborative development and approval of open interna-

tional, mainly XML-based, standards.

Key Points

OASIS was founded in 1993 under the name ‘‘SGML

Open.’’ The initial goal of the organization was to

develop guidelines for interoperability among pro-

ducts using Standard Generalized Markup Language

(SGML). In 1998 it changed name to OASIS to reﬂect

on changing scope of its technical work.

OASIS consists of an open group of member orga-

nizations whose representatives work in committees

developing standards, promoting standards adoption,

product interoperability and standards conformance.

In 2007 OASIS had 5,000 participants representing

600 organizations and individual members in 100

countries. OASIS is governed by a membe r -elected

Board in an annual election process. The boa r d member-

ship is base d on the personal merits of Board nomi nees.

OASIS process allows participants to inﬂuence stan-

dards that affect their business, contribute to standards

advancement and start new standards. The process is

designed to promote industry consensus. OASIS strategy

values creativity and consensus over conformity and

control. It relies on the market to determine the particu-

lar approach taken in the development of sometimes

overlapping standards.

OASIS maintains collaborative relationships

with the International Electrotechnical Commission

(IEC), International Organization for Standardization

(ISO), International Telecommunication Union (ITU)

and United Nations Electronic Commission for

Europe (UN/ECE), and National Institute of Standards

and Technology (NIST).

Among major accomplishments of the OASIS are

such inﬂuential of standards as a group of ebXML stan-

dards, SAML, XACML, WSRP, WSDM, BPEL, Open-

Document, DITA, DocBook, LegalXML and others.

Cross-references

▶ BPEL

▶ DITA

▶ DocBook

▶ ebXML

▶ eGovernment

▶ Emergency Management

▶ LegalXML

▶ oBIX

▶ Open CSA (SCA, SDO)

▶ OpenDocument

▶ SAML

▶ SOA-RM

▶ UDDI

▶ WS-Security

▶ WSDM

▶ WSRP

Recommended Reading

1. OASIS. Available at: http://www.oasis-open.org

Object Constraint Language

MARTIN GOGOLLA

University of Bremen, Bremen, Germany

Synonyms

OCL

Definition

The Uniﬁed Modeling Language (UML) includes

a textual language called Object Constraint Language

2009 Springer ScienceþBusiness Media, LLC

(OCL). OCL allows users to nav igate class diagrams,

to formulate queries, and to restrict class diagrams

with integrity constraints. From a practical perspective,

the OCL may be viewed as an object-oriented version

of the Structured Query Language (SQL) originally

developed for the relational data model. From a theo-

retical perspective, OCL may be viewed as a variant of

ﬁrst-order predicate logic with quantiﬁers on ﬁnite

domains only. OCL has a well-deﬁned syntax [1,3]

and semantics [2].

Key Points

The central language features in OCL are: naviga-

tion, logical connectives, collections and collection

operations.

Navigation: The navig ation features in OCL allow

users to determine connected objects in the class dia-

gram by using the dot operator ‘‘.’’. Starting with an

expression

expr of start class C, one can apply a

property

propC of class C returning, for example, a

collection of objects of class

D by using the dot opera-

tor:

expr.propC. The expression expr could be a

variable or a single object, for example. The navigation

process can be repeated by writing

expr.propC.

propD

,ifpropD is a propert y of class D.

Logical Connectives: OCL offers the usual logical

connectives for conjunction (

and), disjunction (or),

and negation (

not) as well as the implication

(

implies) and a binary exclusive (xor). An equality

check (=) and a conditional (

if then else endif)is

provided on all types.

Collections: In OCL there are three kinds of collec-

tions: sets, bags, and sequences. A possible collection

element can appear at most once in a set, and the

insertion order in the set does not matter. An element

can appear multiple times in a bag, and the order in

the bag collection does not matter. An element can

appear multiple times in a sequence in which the

order is signiﬁcant. Bags and sequences can be con-

verted to sets with

->asSet(), sets and sequences to

bags with

->asBag(), and sets and bags to sequen-

ces with

->asSequence(). The conversion to

sequences assumes an order on the elements. The

arrow notation is explained in more detail below.

Collection Operations: There is a large number of

operations on collections in OCL. A lot of convenience

and expressibility is based upon them. The most

important operations on all collection types are the

following:

forAll realizes universal quantiﬁcation,

exists is existential quantiﬁcation, select ﬁlters

elements with a predicate,

collect applies a term

to each collection element,

size determines the num-

ber of collection elements,

isEmpty tests for empti-

ness,

includes checks whether a possible element is

included in the collection, and

including builds a

new collection

including a new element.

In addition to the central language features, OCL

also has special operations available only on particular

collection, e.g., the operation

at on sequences for

retrieving an element by its position. All collection

operations are applied with the arrow notation men-

tioned above. Roughly speaking, the dot notation

is used when a property follows, i.e., an attribute or a

role follows, and the arrow notation is employed when

a collection operation follows.

Variables in collection operations: Most collection

operations allow variables to be declared (possibly

including a type speciﬁcation), but the variable may

be dropped if it is not needed.

Retrieving all Current Instances of a Class: Another

important possibility is a feature to retrieve the ﬁnite

set of all current instances of a class by appending

.allInstances to the class name. In order to guar-

antee ﬁnite results

.allInstances cannot be applied

to data types like

String or Integer.

Return types in collection operations: If the collection

operations are applied to an argument of type

Set/

Bag/Sequence(T)

, they behave as follows: forAll

and exists returns a Boolean, select yields Set/

Bag/Sequence(T)

, collect returns Bag/Bag/

Sequence(T’)

, size gives back Integer, isEmpty

yields Boolean, includes returns Boolean, and

including gives back Set/Bag/Sequence(T).

Most notably, the operation

collect(...)

changes the type of a Set(T) collection to a

Bag(T’) collection. The reason for thi s is that term

inside the

collect may evaluate to the same result for

two different collection elements. In order to reﬂect

that the result is captured for each collection element,

the result appears as often as a respective collection

element exists. This convention in OCL resembles the

same approach in SQL: SQL queries with the addition-

al keyword

distinct return a set; plain SQL queries

without

distinct return a bag. In OCL, the conven-

tion is similar: OCL expressions using the additional

conversion

asSet() as in collect(...)->asSet

()

return a set; plain collect(...) expressions

without

asSet() return a bag.

1928

Object Constraint Language

Cross-references

▶ Uniﬁed Modeling Language

Recommended Reading

1. OMG (ed.). OMG Object Constraint Language Speciﬁcation.

OMG, 2007. www.omg.org.

2. Richters M. and Gogolla M. On Formalizing the UML Object

Constraint Language OCL. In Proc. 17th Int. Conf. on Concep-

tual Modeling. 1998, pp. 449–464.

3. Warmer J. and Kleppe A. The Object Constraint Language:

Getting Your Models Ready for MDA. Addison-Wesley, Reading,

MA, 2003.

Object Data Models

SUSAN D. URBAN

,SUZANNE W. DIETRICH

Texas Tech University, Lubbock, TX, USA

Arizona State University, Phoenix, AZ, USA

Synonyms

ODB (object database); OODB (objec t-oriented data-

base); ORDB (object-relational database)

Definition

An object data model provides support for objects as

the basis for modeling in a database application. An

object is an instance of a class, which is a complex type

speciﬁcation that deﬁnes both the state of its instance

ﬁelds and the behavior provided by its methods.

Object features also include a unique object identiﬁer

that can be used to refer to the object, as well as the

organization of data into class hierarchies that support

inheritance of state and behavior. The term object data

model encompasses the data model for both object-

oriented databases (OODBs) and object-relational

databases (ORDBs). OODBs use an object-oriented

programming language as the database language and

provide inherent support for the persistence of objects

with typical database functionality. ORDBs extend

relational databases by providing additional support

for objects.

Historical Background

The relational data model was developed in the 1970’s,

providing a way to organize data into tables with rows

and columns [4]. Relationships between tables were

deﬁned by the concept of foreign keys, where a column

(or multiple columns) in one table contained a

reference to a primary key value (uni que identiﬁer)

in another table. The simplicity of the relational data

model was complemented by its formal foundation on

set theory, thus providing powerful algebraic and cal-

culus-based techniques for querying relational data.

Initially, relational data modeling concepts were used

in business-oriented applications, where tables provided

a natural structure for the organization of data. Users

eventually began to experiment with the use of relational

database concepts in new application domains, such as

engineering design and geographic information systems.

These new application areas required the use of complex

data types that were not supported by the relational

model. Furthermore, database designers were discover-

ing that the process of normalizing data into table form

was affecting performance for the retrieval of large, com-

plex, and hierarchically structured data, requiring nu-

merous join conditions to retrieve data from multiple

tables. Around the same time, object-oriented program-

ming languages (OOPLs) were also beginning to devel-

op, deﬁning the concept of user-deﬁned classes, with

instance ﬁelds, methods, and encapsulation for informa-

tion hiding [14].

The OOPL approach of deﬁning object structure

together with object behavior eventually provided

the basis for the development of Object-Oriented

Database Systems (OODBs) in the mid-1980’s. The

Object-Oriented Database System Manifesto, written

by leading researchers in the database ﬁeld, was the

ﬁrst document to fully outline the characteristics of

OODB tech nology [1]. OOD Bs provided a revolution-

ary concept for data modeling, with data objects

organized as instances of user-deﬁned classes. Classes

were organized into class hierarchies, supporting in-

heritance of attributes and behavior. OODBs differed

from relational technology through the use of inter nal

object identiﬁers, rather than foreign keys, as a means

for deﬁning relationships between classes. OODBs also

provided a more seamless integration of database and

programming language technology, resolving the

impedance mismatch problem that existed for rela-

tional database systems. The impedance mismatch

problem refers to the disparity that exists between

set-oriented relational database access and iterative

one-record-at-a-time host language access. In the

OODB paradigm, the OOPL provides a uniform, ob-

ject-oriented view of data, with a single language for

accessing the database and implementing the database

application.

Object Data Models

1929

The relational database research community res-

ponded to the development of OODBs with the

Third Generation Database System Manifesto, deﬁning

the manner in which relational technolog y can be

extended to support objec t-oriented capabilities [13].

Rowe and Stonebraker developed Postgres as the

ﬁrst object-relational database system (ORDB), illus-

trating an evolutionary approach to integrating object-

oriented and relational concepts [10]. ORDB concepts

parallel those found in OODBs, with the notions

of user-deﬁned data types, object tables formed from

user-deﬁned types, hierarchies of user-deﬁned ty pes

and object tables, rows of object tables with internal

object identiﬁers, and relationships between object

tables that use object identiﬁers as references.

Today, several OODB products exist in the market,

and most relational database products provide some

form of ORDB support. The following section elabo-

rates on the common features of object data models

and then differentiates between OODB and ORDB

modeling concepts.

Foundations

Characteristics of Object Data Models

An object is one of the most fundamental concepts of

the object data model, where an object represents an

entity of interest in a speciﬁc application. An object has

state, describing the speciﬁc structural properties of

the object. An object also has behavior, deﬁn ing the

methods that are used to manipulate the object. Each

method has a signature that includes the method name

as well as the method parameters and types. The state

and behavior of an object is expressed through an

object type deﬁnition, which provides an interface for

the object. Objects of the same interface are collected

into a class, where each objec t is viewed as an instance

of the class. A class deﬁnition supports the concept of

encapsulation, separating the speciﬁcation of a class

from the implementation of its methods. The imple-

mentation of a method can therefore change without

affecting the class interface and the way in which the

interface is used in application code.

When an object of a class is instantiated, the object

is assigned a unique, internal object identiﬁer, or oid

[6]. An oid is immutable, meaning that the value of the

identiﬁer cannot be changed. The state of an object, on

the other hand, is mutable, meaning that the values of

object properties can change . In an object data model,

object identit y is used as the basis for deﬁning

relationships between classes, instead of using object

state, as in the relational model. As a result, the values

of object properties can freely change without affecting

the relationships that exist between objects. Object-

based relationships between classes are referred to as

object references.

Classes in an object model can be organized into

class hierarchies, deﬁning superclass and subclass rela-

tionships between classes. A class hierarchy allows for

the inheritance of the state and behavior of a class,

allowing subclasses to inherit the properties and meth-

ods of its superclasses while extending the subclass

with additional properties or behavior that is speciﬁc

to the subclass. Inheritance hierarchies provide a pow-

erful mechanism to represent generalization/speciali-

zation relationships between classes, which simplify

the speciﬁcation of an object schema, as well as queries

over the schema.

As an example of the above concepts, consider the

Publisher application described in Fig. 1 using a Uni-

ﬁed Modeling Language (UML) class diagram [11]. A

Book is a class that is based on an object type that

deﬁnes the state of a book (isbn, title, and listPrice), as

well as the behavior of a book (the method calcBook-

Sales for calculating the total sales of a book based on

customer purchases). Publisher, Person, Author, and

Customer are additional classes, also having state and

behavior. Since authors and custom ers are speciﬁc

ty pes of people, the Author and Customer classes are

deﬁned to be subclasses of Person. Since personName

and address are common to authors and customers,

these attributes are deﬁned at the Person level and

inherited by instances of the Author and Customer

classes. Furthermore, Author introduces additional

state and behavior that is speciﬁc to authors, deﬁning

the date (authorSince) when an author ﬁrst wrote a

book as well as a method (calcAuthorBookSales) for

calculating the total sales of the author’s books. The

Customer class similar ly introduces state and behavior

that is speciﬁc to a customer.

Relationships are also deﬁned between the classes

of the application:



A book is authored by one or more authors; an

author writes many books



A book is published by one publisher ; a publisher

publishes many books



A book is bought by many customers; a customer

buys many books, also recording the date of each

purchase

1930

Object Data Models

For each relationship, speciﬁc instances of each

class are related based on the object identity of each

instance. For example, a book will establish a relation-

ship to the publisher of the book using the oid of the

publisher. In the relational model, the publisher name

would be used as a foreign key to establish the rela-

tionship. If the publisher name changes, then the

change in name must be propagated to the book that

references the publisher. In the object data model, such

changes in state do not affect relationships between

objects since the relationship is based on an immuta-

ble, internal object identity.

A generic object model, such as the one shown in

Fig. 1, can be mapped to either an object-oriented data

model or an object-relational data model. The follow-

ing subsections use the Publisher application in Fig. 1

to illustrate and explain OODB and ORDB approaches

to object data modeling.

Object-Oriented Data Model

An object-oriented database (OODB) is a term typi-

cally used to refer to a database that uses objects as a

building block and an object-oriented programming

language as the database language. The database sys-

tem supports the persistence of objects along with the

features of concurrency and recovery control with efﬁ-

cient access and an ad hoc query language.

The Object Data Standard [2] developed as a stan-

dard to describe an object model, including a deﬁni-

tion language for an object schema, and an ad-hoc

query language. The object model supports the speci-

ﬁcation of classes having attributes and relationships

between objects and the behavior of the class w ith

methods. The Object Deﬁnition Language (ODL) pro-

vides a standard language for the speciﬁcation of an

object schema including properties and method signa-

tures. A property is either an attribute, representing an

instance ﬁeld that describes the object, or a relation-

ship, representing associations between objects. In

ODL, relationships represent bidirectional associations

with the database system being responsible for main-

taining the integrity of the inverse association. An

attribute can be used to deﬁne a unidirectional associ-

ation. If needed, the association can be derived in the

other direction using a method speciﬁcation. The de-

cision is based on trade-offs of storing and maintaining

the association versus deriving the inverse direction on

demand.

Fig. 2 provides an ODL speciﬁcation of the Pub-

lisher application. Each class has a named extent,

which represents the set of objects of that type. The

Author and Customer classe s inherit from the Person

class, extending each subclass with specialized attri-

butes. The Book class has the isbn attribute that

forms a key, being a unique value across all books.

The association between Author and Book is repre-

sented as an inverse relationship, and the cardinality

of the association is many-to-many since an author can

write many books and a book can be written by multi-

ple authors. The set collection type models multiple

Object Data Models. Figure 1. The publisher object data model.

Object Data Models

1931

books and authors. Since the Purchase association

class from Fig. 1 has an attribute describing the associ-

ation, Purchase is modeled in ODL using reiﬁcation,

which is the process of transforming an abstract con-

cept, such as an association, into a class. As a result, the

Purchase class in Fig. 2 represents the many-to-many

association between Book and Customer. Each in-

stance of the Purchase class represents the purchase

of a book by a customer. The Purchase class has the

dateOfPurchase instance ﬁeld, as well as two relation-

ships indicating which Book (bookPurchased) and

which Customer (purchasedBy) is involved in the pur-

chase. The inverse relationships in Book (boughtBy)

and Customer (buys) are related to instances of the

Purchase class.

This ODL speciﬁcation forms the basis of the deﬁ-

nition of the object schema within the particular

OOPL used with the OODB, such as C++, Java, and

Smalltalk. The speciﬁcation of the sch ema and the

method implementation using a given OOPL is

known as a language bind ing. In some OODB pro-

ducts, the ODL speciﬁcation of the properties of the

class are used to automatically generate the deﬁnition

of the schema for the OOPL being used.

The stand ard also includes a declarative query lan-

guage known as the Object Query Language (OQL).

The OQL is based on the familiar select-from-where

syntax of SQL. The select clause deﬁnes the structure of

the result of the query. The from clause speciﬁ es vari-

ables that range over collections within the schema,

such as a class extent or a multivalued property. The

where clause provides restrictions on the properties of

the objects that are to be included in the result. Object

references are traversed through the use of dot nota-

tion for single-valued properties and through the from

clause for multivalued properties.

Consider a simple query that ﬁnds the name of a

publisher of a book given its isbn:

select b.publishedBy.publisherName

from books b

where b.isbn = ‘‘0-13-042898-1’’;

This OQL query looks quite si milar to SQL. In the

from clause, the alias b ranges over the books extent.

Object Data Models. Figure 2. ODL schema of the publisher application.

1932

Object Data Models

The where clause locate s the book of interest. The

select clause provides a path expression that nav igates

through the publishedBy single-valued property to

return the name of the publisher.

Consider another query that ﬁnds the title and sales

for books published by Springer-Verlag:

select title: b.title, sales: b.calcBook-

Sales()

from p in publishers, b in p.booksPublished

where p.p ublisherName = ‘‘Springer-Ver lag’’

This query illustrates the alternative syntax for the

alias in the from clause, using the syntax ‘‘variable in

collection’’. The alias p ranges over the publishers ex-

tent, whereas the alias b ranges over the multivalued

relationship booksPublished of each publisher that

satisﬁes the where condition. The select clause returns

the name of each ﬁeld and its value, where sales returns

the results of a method call.

Object-Relational Data Model

An object-relational database (ORDB) refers to a rela-

tional database that has evolved by extending its data

model to support user-deﬁned types along with addi-

tional object features. An ORDB supports the tradi-

tional relational table in addition to introducing the

concept of a typed table, which is similar to a class in

an OODB. A typed table is created based on a user-

deﬁned type (UDT), which provides a way to deﬁne

complex types with support for encapsulation. UDTs

and their corresponding typed tables can be formed into

class hierarchies with inheritance of state and behavior.

The rows (or instances) of a typed table have object

identiﬁers that are referred to as object references.

Object references can be used to deﬁne relationships

between tables that are based on object identity.

Figure 3 presents an ORDB schema of the Publisher

application that is deﬁned using the object-relational

extensions to the SQL standard. The type personUdt is

Object Data Models. Figure 3. ORDB schema of publisher application.

Object Data Models

1933

an example of specifying a UDT. The UDT deﬁnes the

structure of the type by identifying attributes together

with their type deﬁnitions. The phrase ‘‘instantiable

not ﬁnal ref is system generated’’ deﬁnes three proper-

ties of the type:

1. ‘‘Instantiable’’ indicates that the type supports a

constructor function for the creation of instances

of the type. The phrase ‘‘not instantiable’’ can be

used in the case w here the type has a subtype and

instances can only be created at the subtype level.

2. ‘‘Not ﬁnal’’ indicates that the type can be

specialized into a subtype. The phrase ‘‘ﬁnal’’ can

be used to indicate that a type cannot be further

specialized.

3. ‘‘Ref is system generated’’ indicates that the data-

base system is responsible for automatically gener-

ating an internal object identiﬁer. The SQL

standard supports other options for the generation

of object identiﬁers, which include user-speciﬁed

object-identiﬁers as well as identiﬁers that are

derived from oth er attributes.

Deﬁnition of the personUdt type is followed by the

speciﬁcation of the person typed table, which is based

on the personUdt type. The person typed table auto-

matically acquires columns for each of the attributes

deﬁned in personUdt. In addition, the person typed

table has a column for an object identiﬁer that is

associated with every row in the table. The phras e

‘‘ref is personID’’ deﬁnes that the name of the object

identiﬁer column is personID. The deﬁnition of a

ty ped table can add constraints to the columns that

are deﬁned in the type associated with the table. For

example, personName is deﬁned to be a primary key in

the person typed table.

The authorUdt type is deﬁned as a subtype of

personUdt, as indicated by the ‘‘under personUdt’’

clause. In addition to deﬁning the structure of the

ty pe, authorUdt also deﬁnes behavior with the deﬁni-

tion of the calcAuthorBookSales method. Since

authorUdt is a subt ype of personUdt, authorUdt will

inherit the object identiﬁer (personID) deﬁned in per-

sonUdt. For consistency, the author table is also de-

ﬁned to be a subtable of the person object table. The

ty ped table hierarchy therefore parallels the UDT hier-

archy. In a similar manner, customerUdt is deﬁned to

be a subtype of personUdt and the customer typed

table, based on customerUdt, is deﬁned to be a sub-

table of the person table. UDTs and typed tables are

also deﬁned for the Book and Publisher classes from

Fig. 1, as well as the (reiﬁed implementation of the)

Purchase association class.

Figure 3 also illustrates the use of object references

to represent identity-based relationships be tween

UDTs. Recall from the object data model in Fig. 1

that a book is published by one publisher; a publisher

publishes many books. In an ORDB, this relationship

is established through the use of reference types. In the

bookUdt, the publishedBy attribute has the t ype ref

(publisherUdt), indicating that the value of publishedBy

is a reference to the object identiﬁer (publisherID)

of a publisher. In the inverse direction, the type of

booksPublished in the publisherUdt is an array of

ref(bookUdt), indicating that booksPublished is an

array of object references to books. Each attribute deﬁ-

nition includes a scope clause and a ‘‘references are

checked’’ clause. Since a UDT can be used to deﬁne

multiple tables, the scope clause deﬁnes the table of

the object reference. The references clause speciﬁes the

same options for referential integrity of object references

as originally deﬁned for traditional relational tables.

To establish the fact that a book is published by a

speciﬁc publisher, the object identiﬁer of publisher is

retrieved to create the relationship:

update book

set publishedBy = (select publisherID

from publisher

where publisherName =

‘‘Prentice Hall’’)

where isbn = ‘‘0-13-042898-1’’;

A similar update statement can be used to establish

the relationship in the inverse direction by adding the

book oid to the array of object references of the

publisher.

References can be traversed to query information

about relationships. For example, to return the name

of the publisher of a speciﬁc book, the following query

can be used:

select publishedBy.publisherName

from book

where isbn = ‘‘0-13-042898-1’’;

The dot notation in the select clause performs an

implicit join between the book table and the publisher

table, returning the name of the publisher. The deref()

function can also be used to retrieve the entire

structured type associated with a reference value. For

1934

Object Data Models

example, the following query will return the full in-

stance of the publisherUdt t ype, rather than just the

publisherName:

select deref(publishedBy)

from book

where isbn = ‘‘0-13-042898-1’’;

In this case, the result of the query is a value of

ty pe publisherUdt, containing the publisher name

and the array of references to books published by the

publisher.

Key Applications

Computer-Aided Design, Geographic Information

Systems, Computer-Aided Software Engineering, Em-

bedded Systems, Real-time Control Systems.

Cross-references

▶ Conceptual Schema Design

▶ Database Design

▶ Extended Entity-Relationship Model

▶ OQL

▶ Relational Model

▶ Semantic Data Model

▶ Uniﬁed Modeling Language

Recommended Reading

1. Atkinson M., Bancilhon F., DeWitt D., Dittrich K., Maier D., and

Zdonik S. The Object-Oriented Database System Manifesto. In

Proc. 1st Int. Conf. on Deductive and Object-Oriented Data-

bases, North Holland, 1990.

2. Cattell R.G.G., Barry D.K., Berler M., Eastman J., Jordan D.,

Russell C., Schadow O., Stanienda T., and Velez F. (eds.). The

Object Data Standard: ODMG 3.0 Morgan Kaufmann,

San Mateo, CA, 2000.

3. Chaudhri A. and Zicari R. (eds.). Succeeding with Object

Databases: A Practical Look at Today’s Implementations with

Java and XML. J. Wiley, New York, 2000.

4. Codd E.F. A relational model of data for large shared data banks.

Comm. ACM, 13(6), 1970.

5. Dietrich S.W. and Urban S.D. An Advanced Course in Database

Systems: Beyond Relational Databases. Prentice Hall, Upper

Saddle River, NJ, 2005.

6. Koshaﬁan S. and Copeland G. Object identity. ACM SIGPLAN

Not., 20(11), 1986.

7. Loomis M.E.S. and Chaudhri A. (eds.). Object Databases in

Practice: Prentice Hall, Upper Saddle River, NJ, 1997.

8. Melton J. Advanced SQL:1999: Understanding Object-Relational

and Other Advanced Features. Morgan Kaufmann, San Mateo,

CA, 2002.

9. Object Database Management Systems: The Resource Portal for

Education and Research, http://odbms.org/

10. Rowe L. and Stonebraker M. The Postgres Data Model. In Proc.

13th Int. Conf. on Very Large Data Bases. 1987.

11. Rumbaugh J., Jacobson I., and Booch G. The Uniﬁed Modeling

Language Reference Manual. Addison-Wesley, Reading, MA,

1991.

12. Stonebraker M. Object-Relational DBMSs: The Next Great

Wave. Morgan Kaufmann, San Mateo, CA, 1995.

13. Stonebraker M., Rowe L., Lindsay B., Gray J., Carey M., Brodie

M., Bernstein P., and Beech D. Third generation database system

manifesto. ACM SIGMOD Rec., 19(3), 1990.

14. Stroustrup B. The C++ Programming Language, 3rd edn.

Reading, MA. Addison-Wesley, Reading, MA, 1997.

15. Zdonik S.B. and Maier D. Readings in Object-Oriented Database

Systems. Morgan Kaufmann, San Mateo, CA, 1990.

Object Detection and Recognition

▶ Automatic Image Annotation

Object Flow Diagrams

▶ Activity Diagrams

Object Identification

▶ Object Recognition

Object Identification

▶ Semantic Data Integration for Life Science Entities

Object Identifier

▶ Object Identity

Object Identity

SUSAN D. URBAN

,SUZANNE W. DIETRICH

Texas Tech University, Lubbock, TX, USA

Arizona State University, Phoenix, AZ, USA

Synonyms

Object identiﬁer; Oid; Object reference

Object Identity

1935

Definition

Object identity is a property of data that is created

in the context of an object data model, where an

object is assigned a unique internal object identiﬁer,

or oid. The object identiﬁer is used to deﬁne associa-

tions between objec ts and to support retrieval and

comparison of object-oriented data based on the inter-

nal identiﬁer rather than the attribute values of

an object.

Key Points

In an object data model, an object is created as

an instance of a class. An object has an object identi-

ﬁer as well as a state. An object identiﬁer i s i mmuta-

ble, meaning that the value of the object identiﬁer

cannot change over the lifetime of the object. The

state, on the other hand, is mutable, representing

the attribu tes that describe the object and the rela-

tionships that deﬁne associations among objects .

Relationships in an object data model are deﬁned

using object references based on internal object iden-

tiﬁers rather than attribute values as in a relational

data model. As a result, the attribute values of an

object can freely change without affecting identit y-

based relationships.

Variables that contain object references can be

compared using either object identity or object equali-

ty. Two object references are identical if they contain

the same object identiﬁers. In contrast, two object

references, that possibly contain different object iden-

tiﬁers, are equal if the values of attributes and relation-

ships in each object state are identical. Shallow equality

is the process of comparing the immediate values of

attributes and relationships. Deep equality involves

the traversal of object references in the comparison

process. Query languages for objects must incorporate

operators to distinguish between object identity

and object equality in the speciﬁ cation of object

queries.

Cross-references

▶ Conceptual Schema Design

▶ Extended Entity-Relationship Model

▶ Object Data Models

▶ Object-Role Modeling

▶ Semantic Data Model

▶ Uniﬁed Modeling Language

Recommended Reading

1. Beeri C. and Thalheim B. Identiﬁcation as a Primitive of

Database Models. In Proc. 7th Int. Workshop on Foundations

of Models and Languages for Data and Objects, 1999.

2. Koshaﬁan S. and Copeland G. Object identity. ACM SIGPLAN

Not., 20(11), 1986.

Object Labeling

▶ Object Recognition

Object Monitor

▶ Transactional Middleware

Object Query Language

▶ OQL

Object Recognition

MING-HSUAN YANG

University of California at Merced, Merced, CA, USA

Synonyms

Object identiﬁcation; Object labeling

Definition

Object recognition is concerned with determining the

identity of an object being observed in the image from

a set of know n labels. Oftentimes, it is assumed that the

object be ing observed has been detected or there is a

single object in the image.

Historical Background

As the holy grail of computer vision research is to tell a

stor y from a single image or a sequence of images,

object recognition has been studied for more than

four decades [9,22]. Signiﬁcant efforts have been

spent to develop representation schemes and algo-

rithms aiming at recognizing generic objects in images

1936

Object Labeling