Binayak Niraula
  • Skills
  • Projects
  • About
  • Blogs
  • Notes
  • Skills
  • Projects
  • About
  • Blogs
  • Notes

In this notes

  • Enhanced Entity Relationship Model and Relational Model
  • Object and Object Relational Databases
  • Query Processing and Optimization
  • Distributed Databases, NOSQL Systems and Big Data
  • Advanced Database Models, Systems and Applications

Object and Object Relational Databases

Binayak Niraula | Mon Jan 19 2026

Table of Contents

  1. Object Database Concepts
  2. Features of Object Oriented Database
  3. Object Database Extensions to SQL
  4. The ODMG Object Model
  5. Object Defination Language
  6. Object Database Conceptual Design
  7. Object Query Language
  8. Language Binding in ODMG Standard
  9. Object Relational Model
  10. Differences between OODBMS and RDBMS
  11. Persistent vs Transient Objects

Object Database Concepts

Object-oriented databases are databases that represent data in the form of objects and classes. In object-oriented terminology, an object is a real-world entity and a class is a collection of objects. Object-oriented databases follow the fundamental principles of object-oriented programming. The combination of relational model features (concurrency, transaction, and recovery) with object-oriented principles results in an object-oriented database model. Object-oriented databases add the database functionality to the object programming languages, creating more manageable code bases.

The object-oriented database model is an alternative implementation to that of a relational model. An object-oriented database management system is a hybrid application that uses a combination of object-oriented and relational database principles to process data.

We can use the following formula to outline the OODBM:

Object-oriented programming + relational database features = object-oriented database model.

Main Goal of OODBM

The main goal of object-oriented databases is to combine the advantages of object-oriented technologies and traditional relational databases. On the one hand, object orientation helps with improving the modeling of real-world concepts in the database. On the other hand, basic database capabilities are needed for ensuring persistent and concurrent sharing of information in application.

As for object-oriented databases, we can define object orientation as the combination of abstract data typing, inheritance, and object identity. We can define persistence, concurrency, transaction, recovery, querying, versioning, integrity, security, and performance as the basic database capabilities.

Integrating this definition of object-oriented with the definition of the basic database capabilities gives us the basis for an object-oriented database.

Features of Object Oriented Database

1. Objects and Identity

In an object-oriented database, each real-world entity is represented by an object. This object has a state and a behavior. The combination of the current values of an object's attributes defines the object's state. A set of methods acting on an object's state defines the object's behavior.

For example, let us consider a real-world entity called a Student. A student has states or properties such as name, date of birth, address, etc. Similarly, the student has behaviors or methods, including attending classes, writing exams, paying fees, etc.

Each object in the database is defined by a unique object identifier. There are certain differences between keys and object identifiers.

Differences Between Keys and Object Identifiers

On this page

  • Object Database Concepts
  • Features of Object Oriented Database
  • Object Database Extensions to SQL
  • The ODMG Object Model
  • Object Defination Language
  • Object Database Conceptual Design
  • Object Query Language
  • Language Binding in ODMG Standard
  • Object Relational Model
  • Differences between OODBMS and RDBMS
  • Persistent vs Transient Objects
FeatureKeyObject Identifier (OID)
DefinitionAn attribute value or a set of attribute values (e.g., an employee number).A unique identifier defined by the database for each object.
State DependencyDependent on the object's state; it can be modified (at least theoretically).Independent from an object's state.
IdentityTwo objects with the same attribute values share the same key.Two objects have different OIDs even if all their attribute values (state) are the same.
Uniqueness ScopeUnique within a certain relation only.Unique in the whole database.
ControlCan be changed by the database user by performing a modification operation.Generated by the database system; the user has no control over them.

Using object identifiers comes with a set of advantages. The database user need not to be concerned with defining keys for each relation and it gives a better performance as handling of object identifiers is implemented on a low level by the system.

2. Encapsulation

Encapsulation is an important object-oriented feature. This hides the implementation details from the end-users and displays only the needed descriptions. It was created for making a clear distinction between the specification and the implementation of an operation and in this way for enabling modularity.

Encapsulation derives from the notion of abstract data types, including the distinction of interfaces and implementation. An interface specifies the operation that can be invoked on an object. This is the only part of the object that is visible from outside. An implementation is an object's data representing the object's state and implementation of the object's method. Implementation details are not visible from the outside object.

3. Classes and Instantiation

A class is a set of objects that have the exactly same internal structure. A class defines the implementation of an object and a type describes the way the object can be used. The term instantiation aims that a class definition can be used to generate a set of objects that share the same structure and behavior. A class specifies the structure, a set of attributes, a set of operations, and a set of methods which implement the operations.

4. Inheritance

Inheritance is used to define a class as a subclass of an already existing superclass. The subclass inherits all the attributes and methods from the superclass, and it can add its own or redefine its own attributes and methods. This concept is an important mechanism for supporting reusability. Identical parts of the structure of two different classes may be defined only once in common superclass. In this way, the less code has to be written.

5. Overloading, Overriding and Late Binding

  • Overloading

    In an Object-Oriented Database, overloading refers to defining multiple methods with the same name within a class, but with different parameter lists. The OODB determines which method to execute based on the arguments passed.

  • Overriding

    Overriding in an OODB occurs when a subclass provides its own implementation of a method that is already defined in its superclass. This allows objects of derived classes stored in the database to exhibit specialized behavior.

  • Late Binding

    In an Object-Oriented Database, late binding means that the method call is resolved at runtime, depending on the actual class of the object retrieved from the database. This enables polymorphic behavior when accessing persistent objects.

Advantages of OODBMS

  • Enhanced modeling capabilities since data are more closer to real world.
  • Extensibility: Allows new data types to be built from existing types.
  • Capable of handling a large variety of data types. For example, pictures, videos, voice, text, numbers and so on.
  • More expressive query language.
  • Support for schema evolution
  • Support for long-duration, transactions.
  • Applicability to advanced database applications
  • Improved performance.

Disadvantages of OODBMS

  • Lack of universal data model - there is no universally agreed data model for it.
  • Lack of experience - we do not yet have the level of experience that we have with traditional systems.
  • Lack of standards.
  • Increased complexity.
  • Lack of support for views mechanism
  • Lack of support for security.

Object Database Extensions to SQL

SQL is a standard language for RDBMS. In SQL3, features of object-oriented databases were incorporated into SQL standards. The relational model with object database enhancement is sometimes referred to as the object-relational model. The features of object database that have been included in SQL are:

  • Type constructor have been added to specify complex objects. Basically two types of constructors: row type (tuple or struct constructor) and collection (set, list and bag constructor) type are added.

  • Mechanism of specifying object identifier through use of the reference types is included.

  • Encapsulation of operation is provided through mechanism of user-defined type.

  • Inheritance mechanisms are provided using keyword UNDER.

User-Defined Types Example

    CREATE TYPE STREET_ADDR_TYPE AS 
    (
        STREET_NUM VARCHAR (5),
        STREET_NAME VARCHAR (25),
        APT_NO VARCHAR (5),
        SUITE_NO VARCHAR (5)
    )

    CREATE TYPE USA_ADDR-TYPE AS
    (
        STREET_ADDR STREET_ADDR_TYPE,
        CITY VARCHAR (5),
        ZIP VARCHAR (10)
    )

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. The ODMG stands for Object Data Management Group. 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 the field where the same terms were sometimes used to describe different concepts. ODMG is made up of parts, some of which are as follows:

  • The object model
  • Object Definition Language
  • Object Query Language
  • Binding to object-oriented programming language.

ODMG characteristics

  • Easy to link with programming language,
  • No need for user-defined keys,
  • Easy modeling
  • Can store non-textual data.

Advantage

  • Speed - access to data can be faster because an object can be retrieved directly,
  • Improved performance - base for object-oriented programming,
  • Extensibility - any kinds of data structures are used to hold data,
  • Capable of handling variety of data,
  • Avoids the impedance mismatch.

Object Defination Language

Object Definition Language is a language used in the context of object-oriented databases to define the structure and characteristics of objects within a database. In ODL, data is organized and stored as objects rather than in traditional relational tables. Some common elements found in an ODL include classes, attributes, relationships, inheritance, methods, constraints.

ODL provides a powerful and expressive language for defining object-oriented database schemas. It enables the modeling and organization of data in a way that closely aligns with the principles of object-oriented programming, offering flexibility, modularity, and extensibility in database design.

Class Declarations:

Interface <name> {
     elements = attributes, relationships, methods 
    }

Element Declarations:

attributes (<type>: <name>)
relationship (<type>: <name>)

Example:

Type Data Tuple (
    year, day, month
)

Type Year, day, month integer

Interface Manager {
    Keys id;
    Attribute String name;
    Attribute String phone;
    relationship set <Employee> employees inverse Employee::manager
}

interface Employee {
   Keys id;
    Attribute String name;
    Attribute Date Start Date;
    relationship Manager inverse Manager::employee
}

Object Database Conceptual Design

Object-oriented database design is the first stage in the object-oriented 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.

The conceptual design has four steps, which are as follows:

1. Data analysis and requirements

The first step in conceptual design is to discover the characteristics of the data elements for information.

  • Information needs: What kind of information is needed?
  • Information users: Who will use the information?
  • Information sources: Where is the information to be found?
  • Information constituents: What data elements are needed to produce the information?

2. Entity-relationship modeling and normalization

For ER modeling, the designer must communicate any necessary appropriate standards to be used in documentation of design.

  • Identify, analyze, and refine business rules.
  • Identify the main entities,
  • Define relationships among entities, * Define attributes, primary keys, and foreign keys for each of the entities,
  • Normalize the entities,
  • Complete the necessary ER diagram,
  • Validate ER model,
  • Modify ER model.

3. Data model verification

In this step, ER model must be verified against the proposed system. Verification requires that the model be run through a series of tests against

  • end-user data views,
  • all required transactions, select, insert, update, and delete operations,
  • access rights, and security,
  • business-imposed data requirements, and constraints.

3. Distributed database design

Although not a requirement for most databases, sometimes a database may need to be distributed among multiple geographically dispersed locations. If the database, data, and processes are to be distributed across the system, portions of a database, known as database fragments, may reside in several physical locations.

Object Query Language

Object Query Language is an SQL-like declarative language that provides a rich environment for efficient querying of database objects, including high-level primitives for object states and structures. The OQL syntax for queries is similar to the syntax of relational standard query language, with additional features of ODMG concepts such as object identity, complex objects operations, inheritance, polymorphism, and relationships. It is designed to work closely with programming languages for which an ODMG binding is defined, such as C++, Java, etc.

Simple OQL Queries

Example: Query to retrieve the names of all departments in the College of Engineering can be written as follows:

 SELECT d.dname 
 FROM d IN departments 
 WHERE d.college = "Engineering".

Here, departments is an entry point which refers to a persistent collection of objects. Whenever a collection is referenced in a OQL query, we should define an iterator variable d that ranges over each object in the collection.

Query Results and Path Expressions

A query doesn't have to follow SELECT...FROM...WHERE structure in the simplest case any persistent name on its own is a query, whose reslut is a reference to that persistent object.

Q1: DEPARTMENTS;

returns a reference to the collection of all persistent DEPARTMENTS objects whose type is set<DEPARTMENTS>.

Q2: CS_DEPARTMENT

returns a reference to individual objects of the DEPARTMENTS.

Names or attribute names are connected using dot notation.

Q3: CS_DEPARTMENT.Chair;
Q3A: CS_DEPARTMENT.Chair.Rank;

Language Binding in ODMG Standard

Language binding in the ODMG standard enables the integration of programming languages with ODMG-compliant databases, enabling developers to work with objects using their preferred programming language through a standardized interface. In the ODMG standard, language bindings are defined for several programming languages such as C++, Java, and Smalltalk.

C++ Language Binding:

The ODMG C++ language binding provides language-transparent extensions that provide facilities for object creation, naming, manipulation, deletion, transactions, and database operations. The C++ binding allows persistence-capable classes created by inheritance.

Java Language Binding

This binding uses established Java language practice and idiom style to be natural to the Java environment and programmers. It adds classes and other constructs to the Java environment to support the ODMG object model, including collections, transactions, and databases, without altering the semantics of the language.

Smalltalk Language Binding

It 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. This binding directly maps all the classes, relationships, transactions, and database operations to standard collection classes and methods.

Object Relational Model

The object-relational model (ORM) is a data model that combines features of both object-oriented programming (OOP) and relational database management system (RDBMS). It aims to bridge the gap between OOP and RDBMS. In the object-relational model, data is organized into objects and have attributes, properties, and methods/functions just like in OOP. These objects can be directly mapped to relational database tables where each object corresponds to the row in the table and each attribute corresponds to a column.

Key Features: Inheritance, Complex Data Types, Object Identity, Methods and Functions, Querying.

Differences between OODBMS and RDBMS

FeatureOODBMSRDBMS
Data StorageData in OODBMS is stored as objects.Data in RDBMS is stored in tabular format.
ComplexityIt can handle large and complex data.It handles simple data.
MethodsOODBMS stores data as well as methods to use it.RDBMS stores data only.
IdentificationOID (Object Identifier) is used to uniquely identify objects.Primary key is used to identify objects.
Query LanguageOODBMS provides powerful query language such as OQL.RDBMS typically uses SQL for querying and manipulating data.

State of an Object

The state of an object refers to the set of values stored in its attributes or properties at any given time. The state defines the current condition or snapshot of an object, including the values of its data and any other relevant information.

Persistent vs Transient Objects

FeaturePersistent ObjectsTransient Objects
ExistenceThese are the objects with long-term existence.These are the objects with short-term existence.
StorageState is stored in a persistent medium (example: databases).State is not automatically stored beyond program execution.
LifespanExists beyond the scope of a single program execution.Exists only during the execution of a program or a specific operation.
PurposeIt enables data persistence and durability.It is used for temporary data processing, immediate computations, etc.
State RetentionState is retained across different program invocations.State is lost once the program or operation ends.