Object Oriented and Object Relational Models
The object oriented model stores objects with identity, state and behaviour. The object relational model adds those ideas to a relational core, which is the compromise most real products chose.
-
DBMS Fundamentals
- Data, Information and Databases
- What a DBMS Is and Why It Exists
- File System versus DBMS
- Advantages and Limitations of a DBMS
- Database Users and the Role of the DBA
- Three Level Architecture and Data Abstraction
- Logical and Physical Data Independence
- Schema, Instance and Metadata
- Database Applications and the Database System Environment
- Database Architecture
- Data Models
-
ER Model
- Entities, Entity Sets and Entity Types
- Types of Attributes in the ER Model
- Keys in the ER Model
- Relationships, Relationship Sets and Degree
- Cardinality and Participation Constraints
- Strong and Weak Entities
- Drawing and Reading ER Diagrams
- Extended ER: Generalisation, Specialisation and Aggregation
- Converting an ER Diagram into Relational Tables
- ER Design Projects
- Relational Model
- Relational Algebra
- Functional Dependencies
-
Normalisation
- Why Normalisation Exists: Anomalies and Redundancy
- First Normal Form
- Second Normal Form and Partial Dependency
- Third Normal Form and Transitive Dependency
- BCNF and BCNF Decomposition
- 4NF, 5NF, Multivalued and Join Dependencies
- Lossless Decomposition and Dependency Preservation
- Complete Worked Normalisation: Unnormalised to BCNF
- Denormalisation and When to Use It
Concept
Programs are written with objects: things that have identity, hold state and carry behaviour, and that inherit from one another. Relations are flat tables of values. The gap between the two is the impedance mismatch, and these two models are the two attempts to close it.
The object oriented model
The database stores objects directly, using the same concepts as an object oriented language.
| Concept | Meaning in the database |
|---|---|
| Object | A thing with identity, state and behaviour. |
| Object identity (OID) | A system generated identity independent of any attribute value. Two objects with identical attributes are still different objects. |
| Class | The type: which attributes and which methods. |
| Attribute | State, which may itself be an object or a collection. |
| Method | Behaviour stored with the data. |
| Inheritance | A class extends another and reuses its definition. |
| Encapsulation | State is reached through methods rather than directly. |
| Complex object | An object containing other objects or collections, with no flattening required. |
Advantages
- No impedance mismatch — the program structure and the stored structure match.
- Complex, nested and multimedia data is stored naturally.
- Behaviour lives with the data.
- Inheritance is supported directly.
Disadvantages
- No universally agreed formal foundation comparable to relational theory.
- Query languages are less standardised, and optimisation is harder.
- Navigating object references reintroduces something close to pointer chasing.
- Smaller ecosystem, fewer tools and fewer people who know it.
The object relational model
Rather than replacing relations, this model extends them. The table stays the fundamental structure, and object features are added on top.
| Extension | What it allows |
|---|---|
| User defined types | A column whose type is defined by you, such as an address type with several fields. |
| Structured types | A single attribute holding several named components. |
| Collection types | Arrays or multisets as attribute values. |
| Type inheritance | One defined type extending another. |
| Methods and routines | Behaviour attached to a type, executed in the database. |
| References | An attribute that refers to a row of another table. |
| Large objects | Storing documents, images and other large values. |
RELATIONAL OBJECT RELATIONAL OBJECT ORIENTED
flat columns columns may be objects with
only structured, arrays, identity, methods
or user defined types and inheritance
strong theory relational theory kept, weaker formal
and optimisation extensions added foundation
most widely used what most mainstream niche, specialised
products actually are workloadsExample
-- Illustration only, to show the SHAPE of each model.
-- Purely relational: an address is flattened into columns
customers ( cust_id, name, street, city, pincode )
-- Object relational: an address is a defined type
-- CREATE TYPE address_t AS ( street VARCHAR(80),
-- city VARCHAR(40),
-- pincode CHAR(6) );
customers ( cust_id, name, home_address address_t )
-- Object oriented: an object holding another object,
-- with behaviour attached
-- class Customer { id; name; Address home; billingCity(); }What happened in practice
Purely object oriented databases found a real but narrow audience — engineering design, scientific and multimedia systems where objects are deeply nested. Mainstream products instead became object relational: they kept relational theory, the optimiser and the tooling, and added types, arrays, large objects, routines and document support.
The impedance mismatch was largely handled a third way: object relational mapping libraries in the application layer, which translate between objects and tables without changing the database model at all.
Common mistakes
- Confusing the object relational model with object relational mapping. The model is a database capability; the mapping is an application library. Same three words, different things.
- Saying object oriented databases failed. They did not become mainstream, which is not the same. They are still used where object structures are genuinely deep.
- Believing object identity is the same as a primary key. A primary key is a value you chose; an OID is generated and independent of every value.
- Assuming storing a document makes a database object oriented. That is a large object or document type, not object identity, inheritance and behaviour.
Exam and interview questions
- What is the impedance mismatch, and which two models try to solve it?
- List six concepts of the object oriented data model.
- Differentiate object identity from a primary key.
- What does the object relational model add to the relational model? Give four extensions.
- Why did object relational succeed commercially where purely object oriented did not?
Practice
- Model a vehicle hierarchy — vehicle, car, truck — in the relational model, then say what an object relational type inheritance would change.
- Give two datasets where a purely object oriented database is genuinely a better fit.
- Explain in three sentences why keeping the relational core mattered for optimisation.
Conclusion
The object oriented model stores real objects with identity, inheritance and behaviour. The object relational model keeps relational foundations and adds those features as extensions — the compromise that mainstream products actually adopted.