OBJECT-ORIENTED DATA MODELLING

Object-Oriented Data Modelling represents data as objects that combine attributes (data) and methods (behavior), mirroring the principles of object-oriented programming such as classes, inheritance, encapsulation, and polymorphism. Instead of separating data from logic, this approach treats real-world entities as self-contained units that include both state and behavior. The goal was to align persistent storage directly with object-oriented application design, removing the need to transform objects into relational tables.

In this model, entities such as Customer, LoanApplication, or LoanOfficer are defined as classes. Each class contains attributes that describe its state and methods that define its behavior. For example, a Customer object may contain attributes like CustomerID, Name, and CreditScore, along with a method such as calculateRisk(). A LoanApplication object may include attributes such as LoanID, Amount, InterestRate, and Status, together with methods like approve() or reject(). Relationships between entities are expressed through object references rather than foreign keys, and inheritance allows specialized types to extend base classes.

Object-Oriented Database Management Systems (OODBMS) gained attention in the late 1980s and 1990s, with products such as ObjectStore, GemStone, and Versant. Standards like ODMG-93 and ODMG 2.0 attempted to formalize object database practices. However, by the early 2000s, pure object databases were largely overtaken by relational databases combined with Object-Relational Mapping (ORM) frameworks such as Hibernate and Entity Framework. These frameworks allowed developers to retain object-oriented programming practices while storing data in relational systems.

In a loan approval scenario, an organization might initially store LoanApplication objects directly in an object database, including both the loan data and the approval logic within the same object. This design feels natural for developers and works well for transactional operations. However, when the organization requires large-scale reporting, regulatory analytics, or cross-portfolio aggregation, the limitations of object databases become evident. Analytical workloads demand declarative querying, flexible joins, and optimized aggregations, strengths of relational systems. As a result, many organizations that experimented with OODBMS eventually migrated to relational platforms.

Object-Oriented Data Modelling offers clear advantages in aligning storage with application code. It supports inheritance, encapsulation, and polymorphism, making complex domains feel intuitive for developers. However, it also introduces challenges. Query capabilities are often more procedural and less flexible than SQL. Analytical use cases can be difficult to support efficiently. Interoperability across systems is limited compared to relational standards.

Normalization forms do not directly apply to object-oriented data modelling because objects are not structured as relational tables governed by functional dependencies. Instead, design is driven by class hierarchies and behavior encapsulation rather than relational integrity rules.

Today, Object-Oriented Data Modelling is largely obsolete as a standalone database paradigm. However, its influence persists. Modern document databases with nested JSON structures reflect object-style thinking, and API payloads often mirror object models. Rather than being a final destination in data modelling evolution, object-oriented modelling served as a bridge between programming paradigms and data persistence strategies.

It remains an important chapter in the history of data modelling, one that reshaped developer expectations, even though relational systems ultimately remained dominant in enterprise environments.