The Object-Oriented Data Model

Object-database systems have developed along two distinct paths:

(1) Object-Oriented Database Systems.

  • The approach is heavily influenced by OO programming languages and can be understood as an attempt to add DBMS functionality to a programming language environment.
  • The Object Database Management Group (ODMG) has developed a standard Object Data Model (ODM) and Object Query Language (OQL), which are the equivalent of the SQL standard for relational database systems.

(2) Object-Relational Database Systems.

ORDB systems can be thought of as an attempt to extend relational database systems with the functionality necessary to support a broader class of application domains, provide a bridge between the relational and object-oriented paradigms. This approach attempts to get the best of both.

  • The SQL:1999 (also known as SQL3) standard extends SQL to incorporate support for ORDB systems
  • RDDMS vendors, such as IBM, Informix, ORACLE have added ORDBMS functionality to their products.

Object and Class

  • A conceptual entity is anything that exists and can be distinctly identified.
  • E.g. a person, an employee, a car, a part
  • In an OO system, all conceptual entities are modeled as objects.
  • An object has structural properties defined by a finite set of attributes and behavioral properties defined by a finite set of methods.
  • Each object is associated with a logical non-reusable and unique object identifier (OID).
  • The OID of an object is independent of the values of its attributes.
  • All objects with the same set of attributes and methods are grouped into a class, and form instances of that class.


  • The domain of an attribute of a non-lexical class A can be one of the following:
  • Case (a) a lexical class such as integer, string.
  • An attribute with this domain is called a data-valued attribute.
  • Case (b) a non-lexical class B. An attribute with this domain is called an entity-valued attribute.


  • A method of an object is invoked by sending a message (which is normally the method name) to the object. Such a message-passing mechanism represents a binary interaction between the sender of the message and the recipient.
  • A method’s specification is represented by a method signature, which provides the method name and information on the types of the method’s input parameters and its results.
  • The implementation of the method is separated from the specification. This provides some degrees of data independence.

One to Many Relationships

  • A one-to-many relationship in a database occurs when each record in Table A may have many linked records in Table B, but each record in Table B may have only one corresponding record in Table A.
  • A one-to-many relationship in a database is the most common relational database design and is at the heart of good design.

Many to Many Relationship

  • A many-to-many relationship in a database occurs when many records in Table A may have many linked records in Table B, also many record in Table B may have many corresponding record in Table A.

Object Hierarchy (IS-A Relationship)
(Generalization and Specialization)

  • Generalization is a process of extracting, from one or more given classes of entities or objects within a particular class by suppressing some detailed differences in the descriptions of the given classes.
  • Given 2 classes X and Y, X ISA Y means that each instance of X is also an instance of Y. We call X a subclass of Y and Y a superclass of X.
  • E.g. Manger is a Employee. Employee is a generalization of various types of employees such as engineer, manager, accountant, clerk, typist, messenger etc. all belonging to the same class in organization.
  • A class hierarchy provides an inheritance mechanism which allows a class to inherit properties (attributes and methods) from its super classes.
  • In single inheritance systems, a class can have at most one direct superclass and therefore can only inherit from that superclass.
  • The class hierarchy forms a tree.
  • In multiple inheritance systems, a class can have more than one direct superclass.
  • The class hierarchy is a lattice.
  • Note: In multiple inheritance systems, a class may inherit properties and methods from different super classes and therefore may have inheritance conflicts.
  • Example: A multiple inheritance example.


  • The converse of generalization is specialization.
  • It creates a new class by adding details to the description of the existing class. Thus, both processes, generalization and specialization, are applicable in a given level of entity hierarchies, also known as type hierarchies.
  • This leads to identification of a super type and sub type depending up on whether the level is higher or lower in the type hierarchy.
  • Eg. Vehicle is the super type of Air Vehicle, Land Vehicle and Water Vehicle.


  • Aggregation is a conceptual process where a collection of concepts treated as a single concept.
  • Eg. A country is a aggregation of development region which are aggregation of district which in turn are aggregation of zones which again aggregation of wards and so on.


  • Classification involves grouping of entities that share common properties in the class over which uniform conditions are applicable.
  • Eg. The class person can be derived from the entities Ram, Sita, Hari etc.

E-R Diagramming Models for Object-Oriented Relationships


  • The Booch method is a technique used in software engineering developed by Grady Booch, while at Rational Software (now part of IBM).
  • An object modeling language and methodology that was widely used in object-oriented analysis and design.
  • Booch method has now been superseded(replaced) by the Unified Modeling Language (UML), which features graphical elements from the Booch method along with elements from the object-modeling technique (OMT) and object-oriented software engineering (OOSE).
  • Methodological aspects of the Booch method have been incorporated into several methodologies and processes, the primary such methodology being the Rational Unified Process (RUP).
  • The Booch method includes six types of diagrams:
    • class,
    • object,
    • state transition,
    • interaction,
    • module and process.

Booch Notation: Classes

  • In Booch Notation: classes are represented using a cloud shape with a dashed border.
  • The cloud shape class has two parts one is the class name and other is its attributes and behavior separated by horizontal line.
  • The attributes and operations or methods are show inside the cloud shape below the horizontal line as shown in fig. below

  • We can represent Different types of class in Booch Notation using a triangle and placing a text inside it.
  • A -Abstract.
  • An abstract class cannot be instantiated because it represents a wide variety of object classes and does not represent any one of them fully.

F – Friend.

  • A friend class allows access to the non-public functions of other classes.


  • A static class provides data

Booch Notation: Object

  • In Booch Notation, Object is also represented as cloud shape closed figure but with solid line as shown in fig below.

Booch Notation: Relationships

Diagram for Booch Notation

Unified Modeling Language (UML)

  • UML is a common language for business analysts, software architects and developers used to describe, specify, design, and document existing or new business processes, structure and behavior of artifacts of software systems.

Types of UML Diagrams

  • UML defines different types of diagrams. They are:
  • class (package)
  • object
  • use case
  • sequence
  • component
  • state machine
  • activity,
  • deployment.

Use case Diagram

  • A use case diagram at its simplest is a representation of a user’s interaction with the system and depicting the specifications of a use case.
  • A use case diagram can portray the different types of users of a system and the various ways that they interact with the system.

Class Diagram

  • In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system’s classes, their attributes, operations (or methods), and the relationships among objects

Integrating Objects into a Relational Model

  • There has been several attempts to integrate the Object oriented Approach with the relational database approach.
  • Different models were developed to create the OODBMS but only few are used commercially.
  • In the due course of time, there have been several models developed to integrate the object oriented feature in Relation model.
  • Most of the commercial Relational DBMS have integrated the feature of Object Oriented features in their systems. Eg. Oracle

The Extended Relational Model Approach

  • Several attempts were made towards achieving greater object orientation within the boundaries.
  • RM/T was first attempt in this direction to capture object orientation.
  • Developed by Edgar F. Codd.
  • However it remained at conceptual level as a tool for a database designer and was never implemented.
  • POSTGRES was first largely successful attempt.
  • STARBURST is a parallel approach with much greater robustness and scope.
  • STARBURST is yet to commercialize.
  • Both POSTGRES and STARBURST are strictly based on practical and commercial necessities for upgradation.
  • ERDBMS products provide a relational data model and query language that have been extended to include many of the features that are typical of ODBMSs.
  • The basic viability of this approach lies in its attractive practical and commercial advantages as possibilities for users to migrating from existing Relational products to advanced new generation object Oriented DBMS technology.

The Semantic Database Approach

  • Semantic database Models and Systems, evolved independently as database extensions.
  • It offers semantic richness and extension for object orientation.
  • Semantic models which were well rooted in object orientation began with the E-R Model and progressively became more sophisticated with such advanced models as SDM, SAM (Semantic Association Model) and IFO.
  • Commercial implementation of SIM established a clear place for semantic systems in the market.
  • Over a decade the commercial semantic DBMS products gradually phased out, making way for object oriented DBMS products.

The Proposed Object Database Standard

  • The Object Database Standard is proposed by Object Data Management Group (ODMG) which was formed in 1991.
  • The Major Components of ODMG are:
    • Object Model
    • Object Definition Language (ODL)
    • Object Query Language (OQL)

The Object Model of ODMG

  • Provides a standard model for object databases
  • Supports object definition via ODL
  • Supports object querying via OQL
  • Supports a variety of data types and type constructors

ODMG Objects and Literals

  • The basic building blocks of the object model are
    • Objects
    • Literals
    • An object has four characteristics
  • Identifier: unique system-wide identifier
  • Name: unique within a particular database and/or program; it is optional
  • Lifetime: persistent vs. transient
  • .Structure: specifies how object is constructed by the type constructor and whether it is an atomic object

ODMG Literals

  • A literal has a current value but not an identifier
  • Three types of literals
    • atomic: predefined; basic data type values (e.g., short, float, boolean, char)
    • structured: values that are constructed by type constructors (e.g., date, struct variables)
    • collection: a collection (e.g., array) of values or objects

ODMG Interface Definition:
An Example

  • Note: interface is ODMG’s keyword for class/type

interface Date:Object {
enum weekday{sun,mon,tue,wed,thu,fri,sat};
enum Month{jan,feb,mar,…,dec};
unsigned short year();
unsigned short month();
unsigned short day();

boolean is_equal(in Date other_date);

Built-in Interfaces for Collection Objects

  • A collection object inherits the basic collection interface, for example:
    • cardinality()
    • is_empty()
    • insert_element()
    • remove_element()
    • contains_element()
    • create_iterator()

Collection Types

  • Collection objects are further specialized into types like a set, list, bag, array, and dictionary
  • Each collection type may provide additional interfaces, for example, a set provides:
    • create_union()
    • create_difference()
    • is_subset_of()
    • is_superset_of()
    • is_proper_subset_of()

Object Inheritance Hierarchy

Atomic Objects

  • Atomic objects are user-defined objects and are defined via keyword class for example:

class Employee (extent all_emplyees key ssn) {
attribute string name;
attribute string ssn;
attribute short age;
relationship Dept works_for;
void reassign(in string new_name);

Class Extents

  • An ODMG object can have an extent defined via a class declaration
    • Each extent is given a name and will contain all persistent objects of that class
    • For Employee class, for example, the extent is called all_employees
    • This is similar to creating an object of type Set<Employee> and making it persistent

Class Key

  • A class key consists of one or more unique attributes
  • For the Employee class, the key is ssn
    • Thus each employee is expected to have a unique ssn
  • Keys can be composite, e.g.,
    • (key dnumber, dname)

Object Factory

  • An object factory is used to generate individual objects via its operations
  • An example:

interface ObjectFactory {
Object new ();

  • new() returns new objects with an object_id
  • One can create their own factory interface by inheriting the above interface

Interface and Class Definition

  • ODMG supports two concepts for specifying object types:
    • Interface
    • Class
  • There are similarities and differences between interfaces and classes
  • Both have behaviors (operations) and state (attributes and relationships)

ODMG Interface

  • An interface is a specification of the abstract behavior of an object type
  • State properties of an interface (i.e., its attributes and relationships) cannot be inherited directly.
  • Objects cannot be instantiated from an interface

ODMG Class

  • A class is a specification of abstract behavior and state of an object type
    • A class is Instantiable
    • Supports “extends” inheritance to allow both state and behavior inheritance among classes
    • Multiple inheritance via “extends” is not allowed

Object Definition Language

  • ODL supports semantics constructs of ODMG
  • ODL is independent of any programming language
  • ODL is used to create object specification (classes and interfaces)
  • ODL is not used for database manipulation

ODL Examples (1)
A Very Simple Class

  • A very simple, straightforward class definition

class Degree {
attribute string college;
attribute string degree;
attribute string year;

ODL Examples (2)
A Class With Key and Extent

  • A class definition with “extent”, “key”, and more elaborate attributes; still relatively straightforward

class Person (extent persons key ssn) {
attribute struct Pname {string fname …} name;
attribute string ssn;
attribute date birthdate;

short age();

Object Query Language

  • OQL is DMG’s query language
  • OQL works closely with programming languages such as C++
  • Embedded OQL statements return objects that are compatible with the type system of the host language
  • OQL’s syntax is similar to SQL with additional features for objects

Simple OQL Queries

  • Basic syntax: select…from…where…

FROM     d in departments
WHERE = ‘Engineering’;

  • An entry point to the database is needed for each query
  • An extent name (e.g., departments in the above example) may serve as an entry point

Iterator Variables

  • Iterator variables are defined whenever a collection is referenced in an OQL query
  • Iterator d in the previous example serves as an iterator and ranges over each object in the collection
  • Syntactical options for specifying an iterator:

Data Type of Query Results

  • The data type of a query result can be any type defined in the ODMG model
  • A query does not have to follow the select…from…where… format
  • A persistent name on its own can serve as a query whose result is a reference to the persistent object. For example,
    • departments; whose type is set<Departments>

Path Expressions

  • A path expression is used to specify a path to attributes and objects in an entry point
  • A path expression starts at a persistent object name (or its iterator variable)
  • The name will be followed by zero or more dot connected relationship or attribute names
  • E.g., departments.chair;

Views as Named Objects

  • The define keyword in OQL is used to specify an identifier for a named query
  • The name should be unique; if not, the results will replace an existing named query
  • Once a query definition is created, it will persist until deleted or redefined
  • A view definition can include parameters

An Example of OQL View

  • 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

Collection Operators

  • OQL supports a number of aggregate operators that can be applied to query results
  • The aggregate operators and operate over a collection and include
  • min, max, count, sum, avg
  • count returns an integer; others return the same type as the collection type

An Example of an OQL
Aggregate Operator

  • To compute the average GPA of all seniors majoring in Business:

avg (select s.gpa from s in students
where s.class = ‘senior’ and
s.majors_in.dname =‘Business’);

Creating Object

  • To create an object with identity, a type name constructor is used
  • For instance, to create a Person we can simply write

Person(name: “Pat”, birthdate: date ’1956-3-28’ , salary: 100,000)

  • The parameters in parentheses allow you to initialize certain properties of the object
  • Those that are not explicitly initialized are given a default value

Didn't Find Any Subjects/Contents?

Click on the contribute button to contribute subjects materials on Study Notes Nepal.


Leave a Reply

Your email address will not be published. Required fields are marked *

Join Our Facebook Community Group

Study Notes Nepal