Object-oriented data models: definition, example, pros and cons

What is an object-oriented data model?

An object-oriented data model describes a database in the same terms a programmer uses for code: classes, objects, attributes, methods and inheritance. The database stores an object as the application sees it, so there is no step that maps objects to rows and back.

Object databases appeared in the mid-1980s. The term dates from around 1985, and GemStone 1.0 shipped in 1986. The Object Data Management Group (ODMG) tried to standardise the model and its query language, OQL, and disbanded in 2001. Many of the ideas were then absorbed into SQL:1999 and into object-relational databases (Wikipedia, Object database, checked October 2026).

That history explains where you meet the model today: in textbooks and DBMS courses as one of the classic data models, in a few specialised products, and, in diluted form, inside relational databases and warehouses.

Example of an object-oriented data model

Take an online store that sells physical and digital products.

In a relational design this is three tables. In an object-oriented model it is one parent class and two subclasses:

• EcommerceProduct has the attributes every product shares: an id, a name and a price. It has a method, finalPrice(), that applies tax.
• PhysicalProduct inherits all of that and adds shipping weight and stock quantity.
• DigitalProduct inherits the same and adds a download link and a licence key.

In code, the model reads like this:

class EcommerceProduct:
    def __init__(self, pid,
                 name, price):
        self.pid = pid
        self.name = name
        self.price = price

    def final_price(self, tax):
        return self.price * (1 + tax)


class DigitalProduct(EcommerceProduct):
    def __init__(self, pid, name,
                 price, link):
        super().__init__(
            pid, name, price)
        self.link = link

An object database stores a DigitalProduct as an object of this class. Asking for it returns the object with its inherited attributes, with no join.

Components of an object-oriented data model

Five terms cover the whole model. Each has a direct counterpart in object-oriented programming.

Objects

An object is one real thing: a specific product, customer or order. It has an identity that does not depend on its values. Two products with the same name and price are still two objects.

Attributes

Attributes are the data an object holds: a product’s name and price. An attribute can be a simple value, a list, or a reference to another object, which is how an order points at its customer.

Methods

Methods are the operations an object supports, such as calculating a final price. Storing behaviour with the data is the main thing the relational model does not do.

Classes

A class is the template: it defines which attributes and methods its objects have. EcommerceProduct is a class, and one laptop in the catalogue is an object of that class.

Inheritance

A subclass takes over the attributes and methods of its parent and adds its own. DigitalProduct does not redefine name and price. It inherits them.

The four principles: inheritance, encapsulation, polymorphism, abstraction

The model follows the same four principles as object-oriented programming.

• Inheritance: shared attributes are defined once, in the parent class.
• Encapsulation: an object’s data is reached through its methods. Code that wants a price calls final_price() and does not read tax tables itself.
• Polymorphism: different classes answer the same method in their own way.
• Abstraction: users of a class see what it does, not how it stores things.

Polymorphism is the easiest to see in a payment example. CreditCardPayment and PayPalPayment are both payments and both respond to process(), each with different steps and different attributes.

Object-oriented vs relational data model

The two models answer different needs, and the comparison is the part most often asked about.

In practice the difference shows in the question being asked. “Give me this order with everything attached to it” suits an object database: it follows references and returns one object. “Total revenue by category for last quarter” suits a relational one: it scans many rows and aggregates, which is what SQL was designed for.

Advantages and disadvantages

Both lists matter for an exam answer and for a design decision.

Advantages

• No mapping layer. The application’s objects are stored as they are, with no object-relational mapping code.
• Complex data fits naturally. Nested structures, documents, media and engineering designs do not have to be split across tables.
• Reuse through inheritance. Shared attributes and methods are defined once.
• Fast navigation. A related object is reached by following a reference, without a search.

Disadvantages

• Weak for ad hoc analysis. Aggregating across millions of objects is not what the model is built for.
• No living standard. Since the ODMG disbanded, each product has its own query language and tooling.
• Small ecosystem. Reporting tools, connectors and hiring all assume SQL.
• Tied to the application. Data shaped as one program’s classes is harder for another program to use.

Where object-oriented data models are used

The model fits applications whose data is a web of complex objects rather than a list of records:

• Computer-aided design and engineering, where one design contains thousands of nested parts.
• Multimedia and document systems, where an item carries its content and its metadata together.
• Geographic information systems, with shapes, layers and the operations on them.
• Embedded and mobile applications, where an object store saves a mapping layer on the device.

Most business systems took a middle road. Object-relational databases keep tables and SQL and add object features. PostgreSQL has table inheritance and user-defined types, and the SQL:1999 standard added structured types.

What it means for analytics and reporting

Analytics warehouses are relational, so a pure object-oriented model is not an option there. Two of its ideas still turn up in daily work.

Nested data. A warehouse column can hold a structure or a list, which stores an object the way the application sent it. This query builds one order with a customer object and a list of items, then totals it. It runs as written in Google BigQuery:

WITH orders AS (
  SELECT
    1001 AS order_id,
    STRUCT(
      'C-17' AS id,
      'Ada Lopez' AS name
    ) AS customer,
    [
      STRUCT('Laptop' AS product,
        1 AS qty,
        1200.0 AS price),
      STRUCT('Mouse' AS product,
        2 AS qty,
        25.0 AS price)
    ] AS items
)
SELECT
  order_id,
  customer.name AS customer,
  (
    SELECT SUM(i.qty * i.price)
    FROM UNNEST(items) AS i
  ) AS order_total
FROM orders

It returns one row: order 1001, Ada Lopez, 1250.0. The order is stored as one object, and SQL unpacks it when a question needs the parts.

Encapsulation. In an object model nobody reads the raw fields. They call the method, so the rule is applied the same way every time. Reporting needs the same guarantee: revenue should come from one definition, not from each report’s own reading of the tables.

That is the role a published Data Mart plays in OWOX Data Marts. An analyst writes the SQL once, describes its output fields and declares how it joins to other Data Marts. Reports in Google Sheets or Data Studio then read that definition instead of the tables behind it. The analyst still writes the SQL. The product publishes and governs it. For the modeling choices that do apply in a warehouse, see types of data models and star schema. To start from a finished design, the industry data models are worked examples, and data modeling in OWOX Data Marts explains how a data model is defined and published there.

Data ModelingWhat is Data Modeling? Process, Types and TechniquesOctober 26, 2026→Data ModelingTypes of Data Models: The Three Levels and Seven Structures, with ExamplesOctober 7, 2026→Data Modeling8 Data Modeling Mistakes and How to Avoid ThemOctober 26, 2026→

See all articles →