Objects and Classes - Object-Oriented Database Model | OneNoughtOne

0/278

Database Management SystemsObject-Oriented Model

Object-Oriented Database Model

LevelIntermediate

Duration60 mins

TopicObject-Oriented Model

1 / 5

Objects and Classes

Rethinking Data Representation

The relational model revolutionized database management by providing a clean, mathematical foundation for data storage and retrieval. Tables, rows, and columns—combined with SQL—became the dominant paradigm for decades. But as software engineering evolved, a fundamental tension emerged: the impedance mismatch between how programmers think about data and how databases store it.

Programmers working in object-oriented languages like Java, C++, or Python naturally think in terms of objects—self-contained entities that bundle data (attributes) with behavior (methods). A Customer isn't just a row of values; it's an entity that can placeOrder(), updateAddress(), or calculateLoyaltyPoints(). The relational model, with its flat tables and value-based relationships, struggles to represent this richness directly.

The Object-Oriented Database Model (OODM) emerged to address this mismatch. Rather than forcing programmers to translate between their mental model and the database's storage model, OODM stores objects directly—preserving their identity, structure, and behavior exactly as they exist in application memory.

What You Will Learn

By the end of this page, you will understand how objects and classes serve as the foundational building blocks of object-oriented databases. You'll grasp object identity versus value equality, the anatomy of database objects, class hierarchies, and why these concepts represent a paradigm shift from relational thinking.

The Object Paradigm

An object in the database context is a direct analog of an object in object-oriented programming. It is a self-contained unit that encapsulates:

State — The current values of the object's attributes (data)
Behavior — The methods or operations that can be performed on the object
Identity — A unique, immutable identifier that distinguishes this object from all others

This triad—state, behavior, identity—forms the conceptual foundation of object-oriented databases. Each element addresses limitations in the relational model.

The Three Pillars of Objects

•State (Attributes) — Unlike relational tuples that are flat and atomic, object state can be arbitrarily complex. An Employee object might contain a nested Address object, a collection of Project references, and computed properties like yearsOfService. This complexity is stored directly, not decomposed into normalized tables.
•Behavior (Methods) — Objects carry their own operations. A BankAccount object knows how to withdraw(), deposit(), and calculateInterest(). This co-location of data and behavior eliminates the artificial separation between database storage and application logic.
•Identity (OID) — Every object possesses a unique Object Identifier (OID) assigned by the database system. This identity is independent of attribute values—two Person objects with identical names and addresses remain distinct objects because they have different OIDs.

Identity vs. Equality

This distinction is crucial. In relational databases, two rows are 'the same' if their primary key values match—a value-based identity. In object databases, identity is existence-based: an object is itself because it exists, not because of what values it holds. This mirrors how we think about real-world entities—you remain you even if you change your name, address, or every measurable attribute.

Object Identity (OID)

Object Identity (OID) is perhaps the most fundamental departure from relational thinking. In the relational model, entities are identified by their key values—a customer is identified by customer_id = 12345. If you need to reference that customer from another table, you copy this value as a foreign key.

This approach has consequences:

Key values can change — What happens when a company restructures and renumbers all customer IDs?
Keys are domain-dependent — Different applications choose different keys for the same real-world entity
References are indirect — Following a foreign key requires a lookup operation

Object Identity eliminates these issues by introducing a system-managed, immutable identifier that:

Is assigned automatically when the object is created
Never changes throughout the object's lifetime
Remains unique across the entire database (often globally unique)
Is completely independent of the object's attribute values
Does not require any lookup—it directly addresses the object in memory or storage

Identity Models Compared
Aspect	Value-Based (Relational)	Object-Based (OODM)
What identifies an entity	Primary key value(s)	System-assigned OID
Can identity change?	Yes (key update)	Never
How are references stored?	Copy of key value (FK)	Direct OID reference
Reference resolution	Lookup via index	Direct pointer traversal
Two entities with same values	Cannot exist (key constraint)	Fully allowed (different OIDs)
Cross-database identity	Application-managed	System-guaranteed unique

Implementation of OIDs:

Different OODBMS implementations use different strategies for OID generation:

Physical OIDs — Based on storage location (segment, page, offset). Extremely fast for access but problematic if objects move.
Logical OIDs — UUID or sequence-based identifiers mapped to physical locations via an indirection table. Allows object relocation without changing identity.
Hybrid approaches — Combine benefits by using logical OIDs with cached physical hints.

Most modern systems prefer logical OIDs for their flexibility, accepting the minor indirection cost for the ability to reorganize storage without affecting application code.

OID Concepts Illustrated

Pseudocode

// In a relational database:
customer_table:
  | customer_id (PK) | name      | email              |
  |------------------|-----------|-------------------|
  | 1001             | Alice     | alice@example.com |
  | 1002             | Bob       | bob@example.com   |
 
order_table:
  | order_id | customer_id (FK) | total  |
  |----------|------------------|--------|
  | 5001     | 1001             | 250.00 |
 
// To find Alice's orders: SELECT * FROM order_table WHERE customer_id = 1001
// This requires an index lookup on customer_id
 
// In an object-oriented database:
Customer object (OID: 0x7F3A2B1C):
  - name: "Alice"
  - email: "alice@example.com"
  - orders: [direct reference to 0x8D4E5F2A, ...]
 
Order object (OID: 0x8D4E5F2A):
  - total: 250.00
  - customer: [direct reference to 0x7F3A2B1C]
 
// Navigation is instant pointer traversal:
// alice.orders  → immediate access, no lookup
// order.customer → immediate access, no lookup

Performance Implications

Direct OID references enable O(1) navigation between related objects—no indexes, no joins, no hash lookups. For applications that traverse complex object graphs (CAD systems, scientific simulations, AI knowledge bases), this direct navigation can provide orders-of-magnitude performance improvements over relational approaches.

Object State and Complex Values

The relational model enforces First Normal Form (1NF): all attribute values must be atomic (indivisible). This constraint, while mathematically elegant, forces artificial decomposition of naturally complex data.

Consider modeling an employee's work history:

Relational approach:

Create a separate work_history table
Link via foreign key employee_id
Normalize further if work history entries have sub-structure
Query using JOINs across multiple tables

Object approach:

Store work history as a collection attribute directly in the Employee object
Each history entry is itself an object with rich structure
Access is direct: employee.workHistory

Object-oriented databases support complex state through several mechanisms:

Complex Value Support in OODM

•Nested Objects — An object can contain other objects as attribute values. A Company object might have a headquarters attribute that is itself an Address object containing street, city, country, and postal code.
•Collection Attributes — Sets, lists, bags, arrays, and maps can be stored directly as attribute values. An Author object might have books: Set<Book> containing references to all their published works.
•Multivalued Attributes — Unlike relational systems where multivalued attributes require separate tables, OODM stores them naturally. A Person can have phoneNumbers: List<String> directly.
•Derived Attributes — Computed values defined by methods. An Employee object might have a yearsOfService attribute computed from hireDate and current date, stored or calculated on access.
•Reference Attributes — Direct pointers to other objects. Unlike foreign keys, these are traversable without lookup. An Order has customer: Customer that directly references the Customer object.

Data Complexity: Relational vs Object-Oriented
Scenario	Relational Representation	Object Representation
Employee with multiple skills	employee table + skill table + employee_skill junction table	Employee.skills: Set<Skill>
Order with line items	order table + order_item table + FK relationships	Order.items: List<OrderItem>
Person with nested address	person table + address table + FK or denormalized columns	Person.address: Address (embedded object)
Document with version history	document table + version table + complex queries	Document.versions: List<Version>
Graph of related entities	Multiple junction tables + recursive queries	Entity.relatedTo: Set<Entity>

The Denormalization Trade-off

Complex state in objects resembles denormalization in relational databases—both avoid joins by storing related data together. The key difference: OODM provides principled ways to share objects (via OID references) rather than copying data. This preserves update consistency while enabling direct access.

Classes as Templates

Just as in object-oriented programming, a class in OODM serves as a template or blueprint that defines:

Attributes — The structure of state that instances will hold
Methods — The operations that can be performed on instances
Constraints — Rules that all instances must satisfy
Relationships — How instances connect to objects of other classes

Every object in the database is an instance of exactly one class. The class defines what the object can be; the instance represents what a specific object actually is.

Class as Schema:

In relational databases, the schema (table definitions) is separate from the data (rows). In OODM, classes serve a similar schema role—they define structure—but with crucial differences:

Classes can have behavior (methods), not just structure
Classes form inheritance hierarchies (covered in the next page)
Class definitions are themselves objects (metaobjects) that can be queried and manipulated

Class Definition Example
ODL/Java Style
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
// Class definition in Object Definition Language (ODL) style
class Employee {
    // Attributes define state structure
    attribute string employeeId;
    attribute string firstName;
    attribute string lastName;
    attribute Date hireDate;
    attribute float salary;
    
    // Complex attribute: embedded object
    attribute Address homeAddress;
    
    // Collection attribute: set of project references
    relationship Set<Project> assignedProjects
        inverse Project::teamMembers;
    
    // Reference to another object
    relationship Department department
        inverse Department::employees;
    
    // Derived attribute: computed from other data
    attribute int yearsOfService = 
        (currentDate - hireDate).years;
    
    // Methods define behavior
    void promote(float raisePercent) {
        this.salary = this.salary * (1 + raisePercent/100);
    }
    
    void assignToProject(Project p) {
        this.assignedProjects.add(p);
        p.teamMembers.add(this);
    }
    
    float calculateBonus() {
        return this.salary * 0.10 * this.yearsOfService;
    }
    
    // Constraints
    constraint salary > 0;
    constraint hireDate <= currentDate;
}

Class Extent:

The extent of a class is the set of all current instances of that class in the database. This is analogous to a relational table containing all rows, but with important differences:

Extent automatically includes instances of subclasses (polymorphic)
Extent can be navigated directly without scanning storage
Extent membership is managed by the system, not explicit insertion

When you create a new object, it automatically becomes part of its class's extent. When you delete an object, it's automatically removed. This automatic extent management simplifies application code.

Classes Are First-Class Objects

In pure OODBMS implementations, class definitions are themselves objects stored in the database. This enables powerful metaprogramming: you can query the schema ('show me all classes with a salary attribute'), dynamically create new classes, or implement schema evolution as data operations rather than DDL commands.

Object Lifecycle

Understanding the lifecycle of database objects is essential for working with OODBMS. Unlike transient programming objects that exist only in memory, database objects have persistence—they survive program termination and system restarts.

The object lifecycle encompasses:

Object Lifecycle Phases

•Creation — A new object is instantiated from a class. The system assigns a unique OID. The object is added to its class extent. Initial attribute values may be set via constructor or defaults.
•Persistence — The object is made persistent (stored in the database). In some systems, this is explicit (call makePersistent()). In others, reachability-based persistence means objects become persistent when referenced by other persistent objects.
•Access — Persistent objects are loaded into memory when accessed. The OODBMS manages this transparently—application code works with objects without explicit load/save operations.
•Modification — Changes to object state are tracked by the system. Depending on the concurrency model, modifications may be buffered, logged, or immediately written.
•Commit/Rollback — Transaction boundaries determine when modifications become permanent. Commit makes changes durable; rollback reverts to the previous consistent state.
•Deletion — Objects can be explicitly deleted or garbage-collected when no longer reachable. Deletion removes the object from its class extent and invalidates its OID.

Persistence by Reachability

•Objects become persistent when referenced by persistent objects
•Mirrors programming language semantics
•No explicit persistence calls needed
•Natural transitive closure of persistence
•Garbage collection can reclaim unreachable objects

Explicit Persistence

•Objects must be explicitly marked persistent
•Clearer control over what gets stored
•Requires discipline in application code
•Risk of orphaned transient objects
•More predictable storage behavior

Transparent Persistence

The ideal OODBMS provides transparent persistence: application code operates on objects without awareness of whether they're in memory or on disk. The system automatically loads objects on access (swizzling) and writes modifications on commit. This transparency dramatically simplifies application development compared to explicit data access layers.

Object Relationships

Relationships between objects in OODM are fundamentally different from relational foreign keys. While relational systems represent relationships as value matches between columns, object databases represent relationships as direct references between objects.

Types of Object Relationships:

Object Relationship Types
Relationship Type	Description	Example
Association	General connection between objects. Can be unidirectional or bidirectional.	Employee works-in Department
Aggregation	Weak 'has-a' relationship. Component can exist independently.	Department has Employees
Composition	Strong 'contains' relationship. Component cannot exist without container.	Order contains OrderItems
Dependency	One object uses another without ownership.	ReportGenerator uses DataSource

Relationship Cardinality:

Like relational models, object relationships have cardinality constraints:

One-to-One (1:1) — Each object relates to at most one other object. Example: Employee has one EmployeeBadge.
One-to-Many (1:N) — One object relates to multiple objects. Example: Department has many Employees.
Many-to-Many (M:N) — Multiple objects on both sides. Example: Students enroll-in Courses.

Unlike relational systems that require junction tables for M:N relationships, OODM handles them naturally through collection-valued attributes on both sides.

Relationship Modeling

ODL

// Bidirectional relationship with inverse specification
class Department {
    attribute string name;
    attribute string building;
    
    // One-to-many: department has many employees
    relationship Set<Employee> employees
        inverse Employee::department;
    
    // One-to-one: department has one manager
    relationship Employee manager
        inverse Employee::managedDepartment;
}
 
class Employee {
    attribute string name;
    attribute float salary;
    
    // Many-to-one: employee belongs to one department
    relationship Department department
        inverse Department::employees;
    
    // One-to-one inverse (optional - not all employees manage)
    relationship Department managedDepartment
        inverse Department::manager;
    
    // Many-to-many: employee works on many projects
    relationship Set<Project> projects
        inverse Project::team;
}
 
class Project {
    attribute string title;
    attribute Date deadline;
    
    // Many-to-many inverse
    relationship Set<Employee> team
        inverse Employee::projects;
}
 
// Usage: Navigation is direct
Employee emp = getEmployeeByName("Alice");
Department dept = emp.department;        // Direct traversal, no join
Set<Project> projects = emp.projects;    // Direct access to collection
String building = emp.department.building; // Chained navigation

Referential Integrity in OODM

When relationships are declared bidirectional with inverse specifications, the OODBMS automatically maintains referential integrity. Adding an employee to a department's employees set automatically sets the employee's department reference—and vice versa. This eliminates a major source of application bugs and data inconsistency.

Comparing Relational and Object Models

To solidify understanding, let's directly compare how the same real-world scenario is modeled in relational versus object-oriented approaches.

Scenario: A library system tracking books, authors, and borrowing history.

SQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
-- Relational Schema for Library
CREATE TABLE Author (
    author_id INT PRIMARY KEY,
    name VARCHAR(100),
    birth_date DATE,
    nationality VARCHAR(50)
);
 
CREATE TABLE Book (
    book_id INT PRIMARY KEY,
    title VARCHAR(200),
    isbn VARCHAR(13),
    publication_year INT,
    page_count INT
);
 
-- Junction table for M:N relationship
CREATE TABLE Book_Author (
    book_id INT REFERENCES Book(book_id),
    author_id INT REFERENCES Author(author_id),
    author_order INT,  -- For co-author ordering
    PRIMARY KEY (book_id, author_id)
);
 
CREATE TABLE Member (
    member_id INT PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(100),
    join_date DATE
);
 
CREATE TABLE Borrowing (
    borrowing_id INT PRIMARY KEY,
    book_id INT REFERENCES Book(book_id),
    member_id INT REFERENCES Member(member_id),
    borrow_date DATE,
    due_date DATE,
    return_date DATE
);
 
-- Query: Find all books by an author with borrowing count
SELECT b.title, COUNT(br.borrowing_id) as borrow_count
FROM Book b
JOIN Book_Author ba ON b.book_id = ba.book_id
JOIN Author a ON ba.author_id = a.author_id
LEFT JOIN Borrowing br ON b.book_id = br.book_id
WHERE a.name = 'James Clear'
GROUP BY b.book_id, b.title;

Key observations:

No junction tables — The M:N relationship between Books and Authors is handled directly through bidirectional collection references.
Behavior with data — Methods like isAvailable(), isOverdue(), and getBorrowCount() live with their data, rather than in application code far from the schema.
Navigation vs. joins — The object model navigates directly (author.books), while relational requires joins across multiple tables.
Natural collections — Ordered lists (List<Author> for co-author ordering) are first-class features, not implemented via extra columns.
Query simplicity — Complex relational queries with GROUP BY become simple method calls on objects.

Summary: Objects and Classes

We've established the foundational concepts of object-oriented databases. Let's consolidate the key insights:

Key Takeaways

•Objects are the fundamental unit — Combining state (attributes), behavior (methods), and identity (OID) into self-contained entities.
•Object Identity is existence-based — OIDs are system-managed, immutable, and independent of attribute values—unlike relational keys.
•Complex state is natural — Nested objects, collections, and references are first-class features, not requiring normalization workarounds.
•Classes serve as templates — Defining structure, behavior, constraints, and relationships for all instances.
•Objects have managed lifecycles — Creation, persistence, access, modification, and deletion are handled transparently.
•Relationships are direct references — Navigation between objects is pointer traversal, not foreign key lookups.
•The paradigm addresses impedance mismatch — Object databases store data the way programmers think about it.

What's Next:

Now that we understand objects and classes, the next page explores inheritance—how class hierarchies enable code and structure reuse, polymorphism, and sophisticated type systems that dramatically reduce redundancy in complex domain models.

Page Complete

You now understand the fundamental building blocks of object-oriented databases. Objects and classes provide a richer, more natural representation of complex data than flat relational tables—at the cost of some mathematical elegance. Next, we'll see how inheritance extends this power.