Object-Oriented Model

Overview

The object-oriented (OO) data model stores data as objects — instances of classes that bundle state (attributes) together with behavior (methods), directly mirroring object-oriented programming languages like C++, Java, or Smalltalk. Each object has a unique Object Identifier (OID) that exists independently of its attribute values (unlike a relational primary key, which is derived from data). This model supports encapsulation, inheritance, and polymorphism as first-class database features, not just application-layer constructs.

Object databases like db4o, ObjectDB, and Versant implement this model, and it saw real adoption in domains with deeply nested, complex structures: CAD/CAM systems, telecom network configuration, and multimedia repositories.

How it works — a worked example

In an OO database for a CAD system, you might define a class hierarchy directly in the database:

class Shape { color; draw(); area(); }
class Circle extends Shape { radius; }
class Rectangle extends Shape { width; height; }

A Circle object is stored as an object — its data and its area() method travel together — and can reference other objects directly by OID (e.g., a Drawing object holding a list of Shape object references), no join needed. Because inheritance is native, querying "all Shapes" naturally polymorphically returns Circles and Rectangles alike.

Edge cases and trade-offs

• No impedance mismatch: this is the OO model's core selling point — application objects are persisted directly, with no translation layer between in-memory objects and stored records (contrast with the relational model's ORM layer).
• Complex objects are natural: nested, recursive, or graph-like object structures (a Drawing containing Shapes containing sub-Shapes) are stored and traversed directly via object references, without joins.
• Weak ad-hoc querying: unlike SQL's universally adopted declarative query language, OO databases never converged on a single standard query language (ODMG's OQL existed but never gained the traction SQL did), making ad-hoc reporting and cross-cutting queries harder.
• Tight coupling to application code: because the schema is literally the class definitions, changing a class definition can require careful schema migration of already-persisted objects — and swapping programming languages is much harder than with a relational database.
• Niche adoption: OO databases never displaced relational databases for mainstream business applications, largely because SQL tooling, reporting ecosystems, and DBA familiarity with relational systems were (and remain) far more mature.

How this differs from the Object-Relational Model (3.5)

Don't conflate this with the Object-Relational model: the OO model is a from-scratch database paradigm where objects (with methods and inheritance) are the fundamental storage unit and there is no underlying table structure. The Object-Relational model, by contrast, is fundamentally still relational (tables, SQL, tuples) but extended with OO features like user-defined types and inheritance — it's evolution, not replacement.

Key takeaways / interview Q&A

Q: What is an Object Identifier (OID) and how does it differ from a relational primary key? A: An OID is a system-generated identity for an object that is independent of its attribute values and never changes, even if all the object's data changes — a relational primary key, by contrast, is a data value (or combination of values) drawn from the attributes themselves.

Q: Why didn't the object-oriented model replace the relational model for mainstream applications? A: Lack of a universally adopted declarative query language, weaker ad-hoc/reporting tooling, and tight coupling between schema and application class definitions made it less practical for general business use, despite eliminating the impedance mismatch.