The ODMG Object Model

• The ODMG object model is the data model upon which the object definition
language (ODL) and object query language (OQL) are based.
• It is meant to provide a standard data model for object databases, just as SQL
describes a standard data model for relational databases.
• It also provides a standard terminology in a field where the same terms were
sometimes used to describe different concepts.
Objects and Literals
• Objects and literals are the basic building blocks of the object model.
• The main difference between the two is that an object has both an object
identifier and a state (or current value), whereas a literal has a value (state) but
no object identifier. In either case, the value can have a complex structure.
• The object state can change over time by modifying the object value. A literal is
basically a constant value, possibly having a complex structure, but it does not
change.
An object has five aspects:
• Identifier
• Name
• lifetime
• Structure
• Creation
1. The object identifier is a unique system-wide identifier (or Object_id). Every
object must have an object identifier.
2. Some objects may optionally be given a unique name within a particular ODMS
—this name can be used to locate the object, and the system should return the
object given that name. Obviously, not all individual objects will have unique
names. Typically, a few objects, mainly those that hold collections of objects of
a particular object type—such as extents—will have a name. These names are
used as entry points to the database; that is, by locating these objects by their
unique name, the user can then locate other objects that are referenced from
these objects. Other important objects in the application may also have unique
names, and it is possible to give more than one name to an object. All names
within a particular ODMS must be unique.
3. The lifetime of an object specifies whether it is a persistent object (that is, a
database object) or transient object (that is, an object in an executing pro-gram
that disappears after the program terminates). Lifetimes are independent of
types—that is, some objects of a particular type may be transient whereas
others may be persistent.
• The structure of an object specifies how the object is constructed by using the
type constructors. The structure specifies whether an object is atomic or not. An
atomic object refers to a single object that follows a user-defined type, such as
Employee or Department. If an object is not atomic, then it will be composed of
other objects. For example, a collection object is not an atomic object, since its
state will be a collection of other objects. In the ODMG model, an atomic object
is any individual user-defined object. All values of the basic built-in data types are
considered to be literals.
• Object creation refers to the manner in which an object can be created. This is
typically accomplished via an operation new for a special Object_Factory
interface. In the object model, a literal is a value that does not have an object
identifier. However, the value may have a simple or complex structure.
There are three types of literals:
• Atomic literals Correspond to the values of basic data types and are predefined.
The basic data types of the object model include long, short, and unsigned
integer numbers (these are specified by the keywords long, short, unsigned long,
and unsigned short in ODL), regular and double precision floating point numbers
(float, double), Boolean values (boolean), single characters (char), character
strings (string), and enumeration types (enum), among others.
• Structured literals Correspond roughly to values that are constructed using the
tuple constructor. The built-in structured literals include Date, Interval,Time,
and Timestamp.
• Collection literals specify a literal value that is a collection of objects or values
but the collection itself does not have an Object_id. The collections in the
object model can be defined by the type generators set<T>, bag<T>, list<T>,
and array<T>, where T is the type of objects or values in the collection. Another
collection type is dictionary <K, V> , which is a collection of associations <K, V>
where each K is a key (a unique search value) associated with a value V; this can
be used to create an index on a collection of values V.
The notation of ODMG uses three concepts: interface, literal, and class. Following
the ODMG terminology, we use the word behavior to refer to operations and state
to refer to properties (attributes and relationships).
An interface specifies only behavior of an object type and is typically non
instantiable (that is, no objects are created corresponding to an interface).
Although an interface may have state properties (attributes and relationships) as
part of its specifications, these cannot be inherited from the interface. Hence, an
interface serves to define operations that can be inherited by other interfaces, as
well as by classes that define the user-defined objects for a particular application
• A class specifies both state (attributes) and behavior (operations) of an object
type, and is instantiable. Hence, database and application objects are typically
created based on the user-specified class declarations that form a database
schema.
• Finally, a literal declaration specifies state but no behavior. Thus, a literal
instance holds a simple or complex structured value but has neither an object
identifier nor encapsulated operations.
Inheritance in the Object Model of ODMG
• In the ODMG object model, two types of inheritance relationships exist:
behavior-only inheritance and state plus behavior inheritance. Behavior
inheritance is also known as ISA or interface inheritance, and is specified by the
colon (:) notation. Hence, in the ODMG object model, behavior inheritance
requires the supertype to be an interface, whereas the subtype could be either
a class or another interface.
• The other inheritance relationship, called EXTENDS inheritance, is specified by
the keyword extends. It is used to inherit both state and behavior strictly among
classes, so both the supertype and the subtype must be classes.
• Multiple inheritance via extends is not permitted.
 GeometryObject

• Interface GeometryObject

Rectangle

• Class Rectangle:GeometryObject
• However, multiple inheritance is allowed for behavior inheritance via the colon
(:) notation. Hence, an interface may inherit behavior from several other
interfaces. A class may also inherit behavior from several inter-faces via colon (:)
notation, in addition to inheriting behavior and state from at most one other
class via extends.
ODL: OBJECT DEFINITION LANGUAGE
Object Definition Language (ODL) is the specification language defining the
interface to object types conforming to the ODMG Object Model. Often
abbreviated by the acronym [Link] language's purpose is to define the structure
of an Entity-relationship diagram.
Class Declarations
interface < name > {elements = attributes, relationships, methods }
Element Declarations
attribute < type > < name > ;
relationship < rangetype > < name > ;
Class manager
attributes(id : string unique
name : string
phone : string
set employees : Tuple { [Employee], Start_Date : Date })

Class Employee
attributes(id : string unique
name : string
Start_Date : Date
manager : [Manager])
• example
Interface Customer{
Attribute string name;
Attribute integer ss#;
Attribute Struct Addr { string street , string city , int zip} address;
Relationship Set <Branch> has-account-at
inverseBranch:branchid;
Key(ss#);
• Conceptual design is the first stage in the database design process. The goal at
this stage is to design a database that is independent of database software and
physical details. The output of this process is a conceptual data model that
describes the main data entities, attributes, relationships, and constraints of a
given problem domain.
Differences between Conceptual Design of ODB and RDB
• OO provide unique system generated OID for each object. In relational model
each relation must have a primary key.
• Objects can have a structure of arbitrary complexity. In Rdbs information about a
complex object is scattered over many relations or objects.
• Instance variables hold the values that define the internal state of the object. An
instance variable is similar to the concept of an attribute in the relational model,
except that instance variables may be encapsulated within the object and thus
are not necessarily visible to external users.
• The insistence on complete encapsulation in early OO data models led to the
argument that relationships should not be explicitly represented but should
instead be described by defining appropriate methods that locate related
objects.
• OO systems provide capabilities for dealing with multiple versions of the same
object. In addition they permit schema evolution which occurs when type
declarations are changed or when new types or relations are created. Schema
evolution operations are already defined in the relational SQL standard.
Mapping an EER Schema to an ODB Schema
It is relatively straightforward to design the type declarations of object classes for
an ODBMS from an EER schema that contains neither categories nor nary relation-
ships with n > 2. However, the operations of classes are not specified in the EER dia-
gram and must be added to the class declarations after the structural mapping is
completed. The outline of the mapping from EER to ODL is as follows:
Step 1: Create an ODL class for each for EER entity subclass. The type of the ODL
class should include all the attributes of the EER class. Multivalued attributes is
declared by using the set, bag or list constructor. Composite attributes are mapped
into a tuple constructor
Step 2: Add relationship properties or reference attributes for each binary
relationship into the ODL classes that participate in the relationship. Depending on
the cardinality ratio of the binary relationship the relationship properties or
reference attributes may be single valued or collection types
Step 3: Include appropriate operations for each class. These are not available from
the EER schema and must be added to the database design by referring to the
original requirements.
Step 4: An ODL class that corresponds to a subclass in the EER schema inherits the
type and methods of its superclass in the ODL schema.
Step 5: Weak entity can be mapped in the same way as regular entity types.
Step 6: Categories (union types) in an EER schema are difficult to map to ODL. It is
possible to create a mapping similar to the EER-to-relational mapping by declaring a
class to represent the category and defining 1:1 relationships between the category
and each of its superclasses.
Step 7: An nary relation with degree n>2 can be mapped into a separate class, with
appropriate references to each participating class.
OQL – for querying the database
• OQL is the the query language in ODMG standard.
• OQL is a superset of the SQL (in select-from-where clauses).
• It can be interactive as well as embedded in other programming languages.
• It is a declarative [Link] can invoke operations written in programming
languages (C++, Java, Smalltalk).
• The operators in the language can be freely [Link] includes operators
for creating collections, arithmetic and logical operators, aggregation, sorting
and grouping.
Language Bindings
The ODMG standard’s Java, C++ and Smalltalk bindings define Object Manipulation
Languages (OMLs) that extend the programming languages to support persistent
objects. The bindings also include support for OQL, navigation and transactions. The
OML enables developers to work inside a single language environment without a
separate database language.
Java Language Binding
The ODMG Java binding adheres to the same principles as the Smalltalk and C++
bindings. The binding uses established Java language practice and style to be natural
to the Java environment and programmers. Instances of existing classes can be
made persistent without changes to source code.
C++ Language Binding
The ODMG C++ binding provides language-transparent extensions that provide
facilities for object creation, naming, manipulation and deletion, and transactions
and database operations. The C++ binding allows persistence-capable classes to be
created by inheritance. OQL and OML can be interspersed, so that OQL queries may
be built in-line to application code and conversely, OQL can call OML.
Smalltalk Language Binding
The ODMG Smalltalk binding provides the ability to store, retrieve and modify
persistent objects in Smalltalk. The binding includes a mechanism to invoke OQL
and procedures for transactions and operations on databases.
Difference between RDBMS and OODBMS
RDBMS stands for Relational Database Management System. It is a database
management system based on the relational model i.e. the data and relationships
are represented by a collection of inter-related tables. It is a DBMS that enables the
user to create, update, administer and interact with a relational database. RDBMS is
the basis for SQL, and for all modern database systems like MS SQL Server, IBM
DB2, Oracle, MySQL, and Microsoft Access.
OODBMS stands for Object-Oriented Database Management System. It is a DBMS
where data is represented in the form of objects, as used in object-oriented
programming. OODB implements object-oriented concepts such as classes of
objects, object identity, polymorphism, encapsulation, and inheritance. An object-
oriented database stores complex data as compared to relational database. Some
examples of OODBMS are Versant Object Database, Objectivity/DB, ObjectStore,
Caché and ZODB.
BASIS RDBMS OODBMS

Stands for Relational Database Stands for Object Oriented Database

Long Form Management System. Management System.

Way of storing Stores data in Entities, defined as Stores data as Objects.

data tables hold specific information.

Data Complexity Handles comparatively simpler data. Handles larger and complex data
than RDBMS.

Class describes a group of objects

Entity type refers to the collection of that have common relationships,
Grouping entity that share a common behaviors, and also have similar
definition. properties.

Stores data as well as methods to

Data Handling RDBMS stores only data. use it.

Data Independence from application

Main Objective program. Data Encapsulation.

An object identifier (OID) is an

Key A Primary key distinctively identifies unambiguous, long-term name for
an object in a table.. any type of object or entity.