Unit 2

Object and Object-Relational Databases

Slide 2- 1
 Introduction
 Database systems that were based on the object data
model were known originally as object-oriented
databases (OODBs) but are now referred to as object
databases (ODBs).
 Traditional data models have certain shortcomings when
more complex database applications must be designed
and implemented. ODBs were developed for applications
that have requirements requiring more complex structures
for stored objects.
 A key feature of object databases is the power they give
the designer to specify both the structure of complex
objects and the operations that can be applied to these
objects.
Slide 2- 2
 Introduction
 Another reason for the creation of object-oriented
databases is the vast increase in the use of object-
oriented programming languages. Object databases are
designed so they can be directly integrated with software
that is developed using these languages.
 Many RDBMS vendors have also incorporated many of
the object database features that has lead to object-
relational or ORDBMSs.
 Many of the concepts of object databases have been
incorporated into the latest SQL standards, leading to
object-relational databases. Object features were
originally introduced in SQL:1999, and then updated in
SQL:2008.
Slide 2- 3
 Introduction
 Although many experimental prototypes and commercial
object-oriented database systems have been created, they
have not found widespread use because of the popularity of
relational and object-relational systems.
 The experimental prototypes included the Orion system
developed at MCC, OpenOODB at Texas Instruments, the Iris
system at Hewlett-Packard laboratories, the Ode system at
AT&T Bell Labs, and the ENCORE/ObServer project at Brown
University. Commercially available systems included
GemStone Object Server of GemStone Systems, ONTOS DB
of Ontos, Objectivity/DB of Objectivity Inc., Versant Object
Database and FastObjects by Versant Corporation (and
Poet), ObjectStore of Object Design, and Ardent Database of
Ardent.
Slide 2- 4
 Introduction
 A consortium of object DBMS vendors and users, called
ODMG, proposed a standard whose current specification
is known as the ODMG 3.0 standard. Object definition
language (ODL) and object query language (OQL) are
part of the ODMG 3.0 standard.
 Object-oriented databases have adopted many of the
concepts that were developed originally for object-
oriented programming languages.

Slide 2- 5
Overview of Object Database
Concepts
 Introduction to Object-Oriented Concepts and Features
• The term object-oriented has its origins in OO programming
languages, or OOPLs.
• Today OO concepts are applied in the areas of databases,
software engineering, knowledge bases, artificial intelligence,
and computer systems in general.
• An object typically has two components: state (value) and
behavior (operations).
• Objects can have a complex data structure as well as specific
operations defined by the programmer.
• Objects in an OOPL exist only during program execution;
therefore, they are called transient objects.

Slide 2- 6
Overview of Object Database
Concepts
• An OO database can extend the existence of objects so that
they are stored permanently in a database, and hence the
objects become persistent objects that exist beyond
program termination and can be retrieved later and shared
by other programs.
• Persistent storage hence requires the incorporation of other
well-known features of database management systems,
such as indexing, concurrency control, and recovery from
failures.
• An OO database system will typically interface with one or
more OO programming languages to provide persistent and
shared object capabilities.

Slide 2- 7
Overview of Object Database
Concepts
• 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. Instance
variables may also be of arbitrarily complex data types.
• Object-oriented systems allow definition of the operations or
functions (behavior) that can be applied to objects of a
particular type.
• Some OO models insist that all operations a user can apply
to an object must be predefined. This forces a complete
encapsulation of objects. complete encapsulation implies
that any simple retrieval requires a predefined operation,
thus making ad hoc queries difficult to specify on the fly.

Slide 2- 8
Overview of Object Database
Concepts
• To encourage encapsulation, an operation is defined in two
parts: signature(or interface) and method(or body).
Signature specifies the operation name and arguments (or
parameters) and method specifies the implementation of the
operation.
• Operations are invoked by passing a message to an object,
which includes the operation name and the parameters. The
object then executes the method for that operation.
• Encapsulation permits modification of the internal structure
of an object, as well as the implementation of its operations,
without the need to disturb the external programs that
invoke these operations. Hence, encapsulation provides a
form of data and operation independence.

Slide 2- 9
Overview of Object Database
Concepts
• Class hierarchies and inheritance permit specification of
new types or classes that inherit much of their structure and/or
operations from previously defined types or classes. This
makes it easier to develop the data types of a system
incrementally and to reuse existing type definitions when
creating new types of objects.
• Operator overloading (or operator polymorphism) refers to
an operation’s ability to refer to several distinct
implementations, depending on the type of object it is applied
to.
• Operator polymorphism may require the use of late binding of
the operation name to the appropriate method at a run-time,
when the type of object to which the operation is applied
becomes known.
Slide 2- 10
Overview of Object Database
Concepts
 Object Identity, and Objects versus Literals
• A unique identity is assigned to each independent object
stored in the database. This unique identity is typically
implemented via a unique, system-generated object
identifier (OID).
• The value of an OID may not be visible to the external user
but is used internally by the system to identify each object
uniquely and to create and manage interobject references.
The OID can be assigned to program variables of the
appropriate type when needed.
• The OID should be immutable. It should be used only once
even if an object is removed from the database. It should
not be assigned to another object.

Slide 2- 11
Overview of Object Database
Concepts
• The OID should not depend on any attribute values of the
object.
• It is also inappropriate to base the OID on the physical
address of the object in storage, since the physical address
can change after a physical reorganization of the database.
• Every object must have an immutable OID, whereas a literal
value has no OID and its value just stands for itself. Thus, a
literal value is typically stored within an object and cannot
be referenced from other objects.
• In many systems, complex structured literal values can also
be created without having a corresponding OID if needed.

Slide 2- 12
Overview of Object Database
Concepts
 Complex Type Structures for Objects and Literals
• Objects and literals may have a type structure of arbitrary
complexity in order to contain all of the necessary
information that describes the object or literal.
• A complex type may be constructed from other types by
nesting of type constructors. The three most basic type
constructors are atom, struct (or tuple), and collection.
• Atom:
o This type constructor includes the basic built-in data types of
the object model and contains atomic (indivisible) single value.
o These are similar to the basic types in many programming
languages, such as, integers, strings, floating-point numbers,
enumerated types, Booleans, and so on.

Slide 2- 13
Overview of Object Database
Concepts
• Struct (or tuple):
o The tuple type constructor is often called a structured type,
since it corresponds to the struct construct in the C
programming.
o A structured type is made up of several components and is also
sometimes referred to as a compound or composite type.
o It is similar to tuples (record types) in the basic relational model.
o More accurately, the struct constructor is not considered to be a
type, but rather a type generator, because many different
structured types can be created.
o The tuple constructor can create structured values and objects
of the form <a1:i1, a2:i2,… , an:in>, where each aj is an attribute
name and each ij is a value or an OID.

Slide 2- 14
Overview of Object Database
Concepts
• Collection (or multivalued):
o These type constructors include the set(T), list(T), bag(T),
array(T), and dictionary(K,T) type constructors.
o These allow part of an object or literal value to include a
collection of other objects or values when needed.
o These constructors are also considered to be type generators
because many different types can be created.
o The set constructor will create objects or literals that are a set of
distinct elements {i1, i2, … , in}, all of the same type.
o The bag constructor (also called a multiset) is similar to a set
except that the elements in a bag need not be distinct.
o The list constructor will create an ordered list [i 1, i2, … , in] of
OIDs or values of the same type. A list is similar to a bag except
that the elements in a list are ordered.

Slide 2- 15
Overview of Object Database
Concepts
o The array constructor creates a single-dimensional array of
elements of the same type. The main difference between array
and list is that a list can have an arbitrary number of elements
whereas an array typically has a maximum size.
o The dictionary constructor creates a collection of key-value
pairs (K, V), where key can be used to retrieve the
corresponding value V.
o The main characteristic of a collection type is that its objects or
values will be a collection of objects or values of the same
type that may be unordered (such as a set or a bag) or
ordered (such as a list or an array).
• An object definition language (ODL) incorporates all these type
constructors and are used to define the objects for an OO
database schema.

Slide 2- 16
Slide 2- 17
Overview of Object Database
Concepts
 Encapsulation of Operations and Persistence of
Objects
• Encapsulation of Operations:
o The concept of encapsulation is one of the main
characteristics of OO languages and systems. It is also related
to the concepts of abstract data types and information hiding.
o In traditional database models and systems this concept was
not applied. For example, relation and its attributes are visible
to operations that access them.
o The concept of encapsulation is applied to database objects in
ODBs by defining the behavior of a type of object based on
the operations that can be externally applied to objects of that
type.

Slide 2- 18
Overview of Object Database
Concepts
o The external users of the object are only made aware of the
interface of the operations, that is, signature (name and
arguments) of the operation. The implementation is hidden
from the external users. The interface part of an operation is
sometimes called the signature, and the operation
implementation is sometimes called the method.
o In general, the implementation of an operation can be
specified in a general-purpose programming language that
provides flexibility and power in defining the operations.
o Since, it is too stringent to completely encapsulate objects, the
whole structure of an object is divided into visible and hidden
attributes (instance variables). Visible attributes can be directly
accessible and the hidden attributes are completely
encapsulated and can be accessed only through operations.

Slide 2- 19
Overview of Object Database
Concepts
o The term class is often used to refer to a type definition, along
with the definitions of the operations for that type. A number of
operations are declared for each class, and the signature
(interface) of each operation is included in the class definition.
A method (implementation) for each operation must be defined
elsewhere using a programming language. Typical operations
include the object constructor operation, which is used to
create a new object, and the destructor operation, which is
used to destroy an object. A number of object modifier
operations can also be declared to modify the states (values)
of various attributes of an object. Additional operations can
retrieve information about the object.
o An operation is typically applied to an object by using the dot
notation. The dot notation is also used to refer to attributes of
an object.

Slide 2- 20
Slide 2- 21
Overview of Object Database
Concepts
• Specifying Object Persistence via Naming and
Reachability:
o Not all objects are meant to be stored permanently in the
database.
o Transient objects exist in the executing program and
disappear once the program terminates.
o Persistent objects are stored in the database and persist
after program termination.
o The typical mechanisms for making an object persistent are
naming and reachability.
o The naming mechanism involves giving an object a unique
persistent name within a particular database.

Slide 2- 22
Overview of Object Database
Concepts
o Since, it is not practical to give names to all objects in a large
database that includes thousands of objects, so most objects
are made persistent by using the second mechanism, called
reachability. The reachability mechanism works by making
the object reachable from some other persistent object. An
object B is said to be reachable from an object A if a sequence
of references in the database lead from object A to object B.
o If we first create a named persistent object N, whose state is a
set of objects of some class C, we can make objects of C
persistent by adding them to the set, thus making them
reachable from N. Hence, N is a named object that defines a
persistent collection of objects of class C. In the object model
standard, N is called the extent of C.

Slide 2- 23
Overview of Object Database
Concepts

Slide 2- 24
Overview of Object Database
Concepts
 Type Hierarchies and Inheritance
• Simplified Model for Inheritance:
o Inheritance allows the definition of new types based on other
predefined types leading to a type (or class) hierarchy.
o A type is defined by assigning it a type name and then defining
a number of visible attributes (instance variables) and
operations (methods) for the type. We use the term function to
refer to both attributes and operations, since they are treated
similarly in a basic introduction to inheritance.
TYPE_NAME: function, function, … , function
o A type definition does not specify arguments of functions to
simplify the discussion. For example,
PERSON: Name, Address, Birth_date, Age, Ssn

Slide 2- 25
Overview of Object Database
Concepts
o A subtype is created when the user must create a new type
that is similar but not identical to an already defined type. The
subtype then inherits all visible functions of the predefined
type, which is referred to as the supertype. A subtype may
also include some additional functions that are specific only to
the subtype. This is also called supertype/subtype relationship.
For example,
EMPLOYEE subtype-of PERSON: Salary, Hire_date, Seniority
o When an object is created, typically it belongs to one or more
of these types that have been declared. For example, an
employee object is of type EMPLOYEE and PERSON (by
inheritance). Each object also becomes a member of one or
more persistent collections of objects (or extents).

Slide 2- 26
Overview of Object Database
Concepts
• Constraints on Extents Corresponding to a Type
Hierarchy:
o An extent is defined to store the collection of persistent objects
for each type or subtype. The constraint is that every object in an
extent that corresponds to a subtype must also be a member of
the extent that corresponds to its supertype.
o Some ODBs have a predefined system type (called the ROOT
class or the OBJECT class) whose extent contains all the objects
in the system. All extents are subsets of the extent
corresponding to the class OBJECT, directly or indirectly.
o An extent is a named persistent object whose value is a
persistent collection that holds a collection of objects of the
same type that are stored permanently in the database. It is also
possible to create a transient collection, which exists
temporarily during the execution of a program.

Slide 2- 27
Overview of Object Database
Concepts
 Other Object-Oriented Concepts
• Polymorphism of Operations (Operator Overloading) :
o Operator overloading allows the same operator name or
symbol to be bound to two or more different implementations
of the operator, depending on the type of objects to which the
operator is applied. In ODBs, a similar situation may occur.
o In strongly typed systems, operator polymorphism can be
done at compile time, since the object types must be known.
This is termed early (or static) binding.
o In systems with weak typing or no typing, the type of the object
to which a function is applied may not be known until runtime
and the function must check the type of object at runtime and
then invoke the appropriate method. This is often referred to
as late (or dynamic) binding.

Slide 2- 28
Overview of Object Database
Concepts
• Multiple Inheritance and Selective Inheritance:
o Multiple inheritance occurs when a certain subtype T is a
subtype of two (or more) types and hence inherits the
functions (attributes and methods) of both supertypes.
o This leads to the creation of a type lattice rather than a type
hierarchy.
o One problem that can occur with multiple inheritance is that
the supertypes from which the subtype inherits may have
distinct functions of the same name, creating an ambiguity.
o The general rule is that if a function is inherited from some
common supertype, then it is inherited only once. In such a
case, there is no ambiguity; the problem only arises if the
functions are distinct in the two supertypes.

Slide 2- 29
Overview of Object Database
Concepts
o Techniques for dealing with ambiguity: (a) System checks for
ambiguity when the subtype is created, and to let the user
explicitly choose which function is to be inherited at this time. (b)
Use some system default. (c) Disallow multiple inheritance
altogether if name ambiguity occurs, instead forcing the user to
change the name of one of the functions in one of the supertypes.
o Some OO systems do not permit multiple inheritance at all. In the
object database standard, multiple inheritance is allowed for
operation inheritance of interfaces, but is not allowed for
EXTENDS inheritance of classes.
o Selective inheritance occurs when a subtype inherits only some
of the functions of a supertype. In this case, an EXCEPT clause
may be used to list the functions in a supertype that are not to be
inherited by the subtype. The mechanism of selective inheritance
is not typically provided in ODBs.

Slide 2- 30
 Object Database Extensions to SQL
 Starting with SQL3 (aka SQL:99), features from object
databases were incorporated into the SQL standard.
 At first, these extensions were known as SQL/Object, but
later they were incorporated in the main part of SQL,
known as SQL/Foundation in SQL:2008.
 The relational model with object database enhancements
is sometimes referred to as the object-relational model.
 Some of the object database features included in SQL:
• Some type constructors have been added to specify
complex objects. These type constructors include the row
(corresponds to tuple constructor), array, set, list, and bag.

Slide 2- 31
Object Database Extensions to SQL
• A mechanism for specifying object identity through the use
of reference type is included.
• Encapsulation of operations is provided through the
mechanism of user-defined types (UDTs) that may include
operations as part of their declaration. In addition, the
concept of user-defined routines (UDRs) allows the
definition of general methods (operations).
• Inheritance using the keyword UNDER.

Slide 2- 32
 Object Database Extensions to SQL
 User-Defined Types Using CREATE TYPE and
Complex Objects:
• SQL provides user-defined types (UDTs) for creating
complex-structured objects and to separate the declaration
of a class/type from the creation of a table (which is the
collection of objects/rows).
• A UDT may be specified in its simplest form using the
following syntax:
CREATE TYPE TYPE_NAME AS ();
• A UDT can be used as either the type for an attribute or as
the type for a table. By using a UDT as the type for an
attribute within another UDT, a complex structure for objects
(tuples) in a table can be created.

Slide 2- 33
Object Database Extensions to SQL
• To allow for collection types in order to create complex-
structured objects, four constructors are now included in
SQL: ARRAY, MULTISET, LIST, and SET.
• An array type can have its elements referenced using the
common notation of square brackets. For example, in
Figure (b) below, PHONES[1] refers to the first location
value in a PHONES attribute. A built-in function
CARDINALITY(PHONES) can return the current number of
elements in an array (or any other collection type).
• The commonly used dot notation is used to refer to
components of a ROW TYPE or a UDT. For example,
ADDR.CITY refers to the CITY component of an ADDR
attribute.

Slide 2- 34
Object Database Extensions to SQL

Slide 2- 35
Object Database Extensions to SQL

Slide 2- 36
Object Database Extensions to SQL

Slide 2- 37
Object Database Extensions to SQL

Slide 2- 38
Object Database Extensions to SQL

Slide 2- 39
Object Database Extensions to SQL

Slide 2- 40
Object Database Extensions to SQL
• If a UDT does not have any operations, it is possible to use
the concept of ROW TYPE to directly create a structured
attribute by using the keyword ROW.

Slide 2- 41
 Object Database Extensions to SQL
 Object Identifiers Using Reference Types:
• Unique system-generated object identifiers can be created
via reference type using REF (see Figure (b) above).
• Alternatively can use primary key as OID as in traditional
relational model.
• In general, the user can specify object identifiers for the
individual rows in a table by using
REF IS <oid_attribute><value_generation_method>;
the oid_attribute will be used to identify individual tuples in the
table. The options for are SYSTEM GENERATED or
DERIVED. In the former case, the system will automatically
generate a unique id for each tuple. In the latter case, user-
provided primary key value to identify tuples is applied.
Slide 2- 42
 Object Database Extensions to SQL
 Creating Tables Based on the UDTs:
• For each UDT that is specified to be instantiable via the
phrase INSTANTIABLE (see Figure (b) above), one or more
tables may be created (See Figure (d) above).
• Noninstantiable UDTs can only be used as types for
attributes, but not as a basis for table creation (see Figure
(a) above).

Slide 2- 43
 Object Database Extensions to SQL
 Encapsulation of Operations:
• A user-defined type can have its own behavioral
specification by specifying methods (or operations) in
addition to the attributes (see Figure (b) above).
• SQL provides certain built-in functions (constructor,
observer function, and mutator function) for user-defined
types. SQL allows these functions to be blocked from public
use; an EXECUTE privilege is needed to have access to
these functions.
• A UDT can have a number of user-defined functions
associated with it. The syntax is:
INSTNCE METHOD <NAME> (<ARGUMENT_LIST>) RETURNS
<RETURN TYPE>;

Slide 2- 44
Object Database Extensions to SQL
• Two types of functions can be defined: internal SQL and
external. Internal functions are written in the extended PSM
(Persistent Stored Modules) language of SQL. External
functions are also written in a host language, with only their
signature (interface) appearing in the UDT definition.
• An external function definition can be declared as follows:
DECLARE EXTERNAL <FUNCTION_NAME> <SIGNATURE>
LANGUAGE <LANGUAGE_NAME>;
• Attributes and functions in UDTs are divided into three
categories: PUBLIC, (visible at the UDT interface),
PRIVATE (not visible at the UDT interface), PROTECTED
(visible only to subtypes).
• It is also possible to define virtual attributes as part of UDTs,
which are computed and updated using functions.
Slide 2- 45
 Object Database Extensions to SQL
 Specifying Inheritance:
• SQL has rules for dealing with type inheritance (specified
via the UNDER keyword) for both types and tables.
• The phrase NOT FINAL must be included in a UDT if
subtypes are allowed to be created under that UDT (see
Figures (b) above).
• In general, we specify the local (specific) attributes and any
additional specific methods for the subtype, which inherits
the attributes and operations (methods) of its supertype.
• SQL also allows table inheritance via the
supertable/subtable facility. This is also specified using
UNDER (see Figure (d) above). Here, a new record that is
inserted into a subtable is also inserted into its supertables.

Slide 2- 46
 Object Database Extensions to SQL
 Specifying Relationship via Reference:
• A component attribute of one tuple may be a reference
(specified using the keyword REF) to a tuple of another (or
possibly the same) table (see Figure (e) above).
• The keyword SCOPE specifies the name of the table whose
tuples can be referenced by the reference attribute. This is
similar to a foreign key, except that the system-generated
OID value is used rather than the primary key value.
• SQL uses a dot notation to build path expressions that refer
to the component attributes of tuples and row types.
However, for an attribute whose type is REF, the
dereferencing symbol –> is used.

Slide 2- 47
 The ODMG Object Model and Object
Database Language ODL
 A consortium of ODB vendors and users, called ODMG
(Object Data Management Group), proposed a standard
that is known as the ODMG-93 or ODMG 1.0 standard.
 This standard was revised into ODMG 2.0, and later to
ODMG 3.0.
 This standard is made up of several parts, including the
object model, the object definition language (ODL), the
object query language (OQL), and the bindings to object-
oriented programming languages.

Slide 2- 48
 The ODMG Object Model and Object
Database Language ODL
 Overview of the Object Model of ODMG:
• The ODMG object model is the data model upon which the
object definition language (ODL) and object query language
(OQL) are based.
• It provides a standard data model for object databases, just
as SQL describes a standard data model for relational
databases.
• Objects and Literals:
o An object has both an object identifier and a state, whereas a
literal has a state but no object identifier.
o In either case, the value can have a complex structure. The
object state can change over time. A literal is basically a
constant value, possibly having a complex structure.

Slide 2- 49
The ODMG Object Model and Object
Database Language ODL
o An object has five aspects: identifier, name, lifetime,
structure, and creation.
1. Every object must have unique system-wide object identifier.
2. Some objects (extents and important objects) may optionally be
given a unique name.
3. The lifetime of an object specifies whether it is a
persistent object or transient object.
4. The structure of an object specifies how the object is
constructed by using the type constructors. The structure
specifies whether an object is atomic (single object of
user defined type) or not (composed of other objects).
5. 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.

Slide 2- 50
The ODMG Object Model and Object
Database Language ODL
o A literal is a value (simple or complex structure) that does not
have an object identifier. There are three types of literals:
atomic, structured, and collection.
1. Atomic literals correspond to the values of basic data types
and are predefined. For example, long, short, unsigned long,
unsigned short, float, double, boolean, char, string, enum etc.
2. Structured literals correspond to the tuple constructor. Built-in
structured literals include Date, Interval, Time, and Timestamp.
User-defined structured literals can be defined as needed.
3. 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
associated with a value V.
Slide 2- 51
The ODMG Object Model and Object
Database Language ODL
o The notation of ODMG uses three concepts: interface, literal,
and class.
1. An interface specifies only behavior of an object type and is
typically noninstantiable. An interface can be inherited by other
interfaces, as well as by classes.
2. A class specifies both state (attributes) and behavior
(operations) of an object type and is instantiable.
3. 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.
o All objects inherit the basic interface operations of Object;
these include operations such as copy (creates a new copy of
the object), delete (deletes the object), and same_as
(compares the object’s identity to another object). Operations
are applied to objects using the dot notation. An alternative to
the dot notation is the arrow notation.
Slide 2- 52
 The ODMG Object Model and Object
Database Language ODL
 Inheritance in the Object Model of ODMG:
• Two types: 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.
Behavior inheritance requires supertype to be an interface,
whereas subtype could be either a class or another interface.
• EXTENDS inheritance, specified by the keyword extends, 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. However, an
interface may inherit behavior from several other interfaces. A
class may also inherit behavior from several interfaces via
colon (:) notation, in addition to inheriting behavior and state
from at most one other class via extends.
Slide 2- 53
 The ODMG Object Model and Object
Database Language ODL
 Built-in Interfaces and Classes in the Object Model:
• All interfaces inherit the basic Object interface.
• Iterator interface is used to create an iterator for a collection
which can iterate over each element in the collection.
• The interfaces set<T>, list<T>, bag<T>, array<T>, and
dictionary<K, V> inherit the operations of the Collection
interface.
• The ODMG object model uses exceptions for reporting errors
or particular conditions.
• Interfaces are not directly instantiable; that is, one cannot
directly create objects based on these interfaces. Rather, the
interfaces can be used to generate user-defined collection
types – of type set, bag, list, array, or dictionary – for a
particular database application.
Slide 2- 54
The ODMG Object Model and Object
Database Language ODL

Slide 2- 55
 The ODMG Object Model and Object
Database Language ODL
 Atomic (User-Defined) Objects:
• These objects are specified using the keyword class in ODL.
Any user-defined object that is not a collection object is called
an atomic object.
• User-defined atomic object type is defined as a class by
specifying its properties and operations.
• The properties define the state of the object and are further
distinguished into attributes and relationships.
• Attribute is a property that describes some aspect of an object.
• A relationship is a property that specifies that two objects in the
database are related. In the object model of ODMG, only
binary relationships are explicitly represented, and each binary
relationship is represented by a pair of inverse references
specified via the keyword relationship.
Slide 2- 56
The ODMG Object Model and Object
Database Language ODL
• The keyword inverse specifies that these two properties
define a single conceptual relationship in inverse directions.
• By specifying inverses, the database system can maintain
the referential integrity of the relationship automatically.
• If the database designer desires to have a relationship to be
represented in only one direction, then it has to be modeled
as an attribute (or operation).
• In addition to attributes and relationships, the designer can
include operations in object type (class) specifications. The
operation signature can also specify the names of
exceptions that can occur during operation execution. The
implementation of the operation will include the code to
raise these exceptions.

Slide 2- 57
 The ODMG Object Model and Object
Database Language ODL
 Extents, Keys, and Factory Objects:
• In the ODMG object model, the database designer can declare
an extent (using the keyword extent) for any object type that is
defined via a class declaration. The extent is given a name,
and it will contain all persistent objects of that class. Hence,
the extent behaves as a set object that holds all persistent
objects of the class. Extents are also used to automatically
enforce the set/subset relationship between the extents of a
supertype and its subtype.
• A class with an extent can have one or more keys. A key
consists of one or more properties (attributes or relationships)
whose values are unique for each object in the extent.
• Factory object is an object that can be used to generate or
create individual objects via its operations.
Slide 2- 58
 The ODMG Object Model and Object
Database Language ODL
 Object Definition Language:
• Object definition language (ODL) is used to create an object
database schema.
• The ODL is designed to support the semantic constructs of
the ODMG object model and is independent of any
particular programming language.
• Its main use is to create object specifications (classes and
interfaces). ODL is not a programming language.
• A user can specify a database schema in ODL
independently of any programming language, and then use
the specific language bindings to specify how ODL
constructs can be mapped to constructs in specific
programming languages.

Slide 2- 59
The ODMG Object Model and Object
Database Language ODL

Slide 2- 60
The ODMG Object Model and Object
Database Language ODL

Slide 2- 61
The ODMG Object Model and Object
Database Language ODL

Slide 2- 62
The ODMG Object Model and Object
Database Language ODL

Slide 2- 63
The ODMG Object Model and Object
Database Language ODL

Slide 2- 64
The ODMG Object Model and Object
Database Language ODL

Slide 2- 65
The ODMG Object Model and Object
Database Language ODL

Slide 2- 66
The ODMG Object Model and Object
Database Language ODL

Slide 2- 67
 Object Database Conceptual Design
 Differences between Conceptual Design of ODB and
RDB:
• One of the main differences between ODB and RDB design
is how relationships are handled. In ODB, relationships are
typically handled by having relationship properties or
reference attributes that include OID(s) of the related
objects. In RDB, relationships among tuples are specified
via foreign keys.
• Another major area of difference between ODB and RDB
design is how inheritance is handled. In ODB, these
structures are built into the model, so the mapping is
achieved by using the inheritance constructs, such as
derived (:) and extends. In relational design, there are
several options to choose from.
Slide 2- 68
Object Database Conceptual Design
• The third major difference is that in ODB design, it is
necessary to specify the operations early on in the design.
The design of operations may be delayed in RDB design.
• There is a philosophical difference between the relational
model and the object model of data in terms of behavioral
specification. The relational model does not mandate the
database designers to predefine a set of valid behaviors or
operations, whereas this is a tacit requirement in the object
model. One of the claimed advantages of the relational
model is the support of ad hoc queries and transactions,
whereas these are against the principle of encapsulation.

Slide 2- 69
 Object Database Conceptual Design
 Mapping an EER Schema to an ODB Schema:
• Step 1. Create an ODL class for each EER entity type. The
ODL class should include all the attributes of the EER entity
type. Declare an extent for each class, and specify any key
attributes as keys of the extent.
• Step 2. Add relationship properties or reference attributes
for each binary relationship into the ODL classes that
participate in the relationship. These may be created in one
or both directions.
• Step 3. Include appropriate operations, constructors, and
destructors 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.

Slide 2- 70
Object Database Conceptual Design
• Step 4. An ODL class that corresponds to a subclass in the
EER schema inherits (via extends) the attributes,
relationships, and methods of its superclass in the ODL
schema. Its specific (local) attributes, relationship
references, and operations are also specified.
• Step 5. Weak entity types can be mapped in the same way
as regular entity types. An alternative mapping is possible
for weak entity types that do not participate in any
relationships except their identifying relationship; these can
be mapped as though they were composite multivalued
attributes of the owner entity type.

Slide 2- 71
Object Database Conceptual Design
• 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 n-ary relationship with degree n > 2 can be
mapped into a separate class, with appropriate references
to each participating class. These references are based on
mapping a 1:N relationship from each class that represents
a participating entity type to the class that represents the n-
ary relationship. An M:N binary relationship, especially if it
contains relationship attributes, may also use this mapping
option, if desired.
Slide 2- 72
 Object Query Language (OQL)
 The object query language OQL is the query language
proposed for the ODMG object model.
 The OQL syntax for queries is similar to the syntax of
SQL, with additional features for ODMG concepts, such
as object identity, complex objects, operations,
inheritance, polymorphism, and relationships.
 Simple OQL Queries, Database Entry Points, and
Iterator Variables:
• The basic OQL syntax is a select … from … where …
structure, as it is for SQL.
• For example, query to retrieve the names of all departments
in the college of ‘Engineering’ can be written as

Slide 2- 73
 Object Query Language (OQL)
select D.Dname
from D in DEPARTMENTS
where D.College = ‘Engineering’;
•An entry point to the database is needed for each query,
which can be any named persistent object. For many queries,
the entry point is the name of the extent of a class.
•Whenever a collection is referenced in an OQL query, we
should define an iterator variable – D in above query – that
ranges over each object in the collection.
•The query selects certain objects from the collection, based
on the conditions specified in the where clause.
•The result of a query would be of type bag for select … from
… and of type set for select distinct … from … , as in SQL.
Slide 2- 74
 Object Query Language (OQL)
• There are three syntactic options for specifying iterator
variables:
D in DEPARTMENTS
DEPARTMENTS D
DEPARTMENTS AS D
Here, we will use the first construct .
• The named objects used as database entry points for OQL
queries are not limited to the names of extents. Any named
persistent object, whether it refers to an atomic (single)
object or to a collection object, can be used as a database
entry point.

Slide 2- 75
 Object Query Language (OQL)
 Query Results and Path Expressions:
• A query does not have to follow the select…from…where…
format.
• In the simplest case, any persistent name on its own can
serve as a query whose result is a reference to that
persistent object, e.g., departments; whose type is
set<Departments>
• A query can also be a persistent name to a single object.
For example, csdepartment; returns reference to that
individual object of type Department.
• Once an entry point is specified, the concept of path
expression can be used to specify a path to related
attributes and objects.

Slide 2- 76
 Object Query Language (OQL)
• A path expression typically starts at a persistent object
name , or at the iterator variable that ranges over individual
objects in a collection.
• The name will be followed by zero or more dot connected
relationship or attribute names, e.g.,
csdepartment.chair;
csdepartment.chair.rank;
csdepartment.has-faculty;
• To find rank of all faculties in csdepartment, we write
select f.rank
from f in csdepartment.has_faculty

Slide 2- 77
 Object Query Language (OQL)
• In general, an OQL query can return a result with a complex
structure specified in the query itself by utilizing the struct
keyword.
select struct (last_name:s.name.lname,
frist_name:s.name.fname)
from s in csdepartment.has_majors;
• We can also use order by as follows:
select struct (last_name:s.name.lname,
frist_name:s.name.fname)
from s in csdepartment.has_majors;
order by last_name asc,first_name desc;

Slide 2- 78
 Object Query Language (OQL)
 Specifying Views as Named Queries:
• The view mechanism in OQL uses the concept of a named
query.
• The define keyword in OQL is used to specify an identifier
for a named query, which must be a unique name among all
named objects, class names, method names, or function
names in the schema.
• If the identifier has the same name as an existing named
query, then the new definition replaces the previous
definition.
• Once a query definition is created, it will persist until deleted
or redefined.
• A view definition can include parameters.
Slide 2- 79
 Object Query Language (OQL)
• A view to include students in a department who have a
minor:
define has_minor(dept_name) as
select s
from s in students
where s.minor_in.dname=dept_name
• has_minor can now be used in queries, e.g.,
has_minor(‘Computer Science’)

Slide 2- 80
 Object Query Language (OQL)
 Extracting Single Elements from Singleton
Collections:
• An OQL query returns a collection. OQL’s element
operator can be used to return a single element from a
singleton collection that contains one element.
element (select d from d in departments)
where d.dname = ‘Software Engineering’);
• If d is empty or has more than one elements, an exception
is raised.

Slide 2- 81
 Object Query Language (OQL)
 Collection Operators (Aggregate Functions,
Quantifiers):
• OQL supports a number of aggregate operators that can be
applied to query results.
• The aggregate operators include min, max, count,
sum, and avg and operate over a collection.
• count returns an integer; others return the same type as
the collection type.
• To compute the average GPA of all seniors majoring in
Business, we write
avg (select s.gpa from s in students
where s.class = ‘senior’ and
s.majors_in.dname =‘Business’);
Slide 2- 82
 Object Query Language (OQL)
• OQL also provides membership and quantification
operators.
o (e in c) is true if e is in the collection c
o (for all e in c: b) is true if all e elements of collection
c satisfy b
o (exists e in c: b) is true if at least one e in collection c
satisfies b
o To retrieve the names of all students who completed CS101,
we write
select s.name.fname s.name.lname
from s in students
where ‘CS101’ in
(select c.name from c in
s.completed_sections.section.of_course);
Slide 2- 83
 Object Query Language (OQL)
 Ordered (Indexed) Collection Expressions:
• Collections that are lists or arrays allow retrieving their
first, last, and ith elements.
• OQL provides additional operators for extracting a sub-
collection and concatenating two lists.
• OQL also provides operators for ordering the results.
• To retrieve the last name of the faculty member who earns
the highest salary, we write
first (select struct
(faculty: f.name.lastname,salary: f.salary)
from f in faculty
ordered by f.salary desc);

Slide 2- 84
 Object Query Language (OQL)
 The Grouping Operator:
• OQL also supports a grouping operator called group by.
• To retrieve average GPA of majors in each department
having >100 majors, we write
select deptname, avg_gpa:
avg (select p.s.gpa from p in partition)
from s in students
group by deptname: s.majors_in.dname
having count (partition) > 100;

Slide 2- 85
Language Binding in the ODMG Standard
 Language binding allows programmers to interact with the
database using familiar programming languages while
ensuring consistency in object management.
 ODMG provides specific language bindings for popular
object-oriented programming languages, such as C++,
Java etc.
 These bindings define how objects are created,
manipulated, and stored in an OODBMS using standard
programming paradigms.

Slide 2- 86