Unit 4: Object-Oriented and Object-Relational Databases

Syllabus:

Objected Oriented and Object Relational Databases: Modeling Complex Data Semantics, Specialization, Generalization, Aggregation and Association, Objects, Object Identity, Equality and Object Reference, Architecture of Object Oriented and Object Relational Databases

1. Modeling Complex Data Semantics

Traditional relational databases excel at handling structured data with simple relationships but face limitations when dealing with complex data semantics found in many modern applications.

1.1 Limitations of the Relational Model

The relational model, despite its theoretical elegance and widespread adoption, faces several limitations when modeling complex real-world entities:

1.1.1 Limited Data Types

Relational databases traditionally support only simple atomic data types:

• Numeric types (integers, floating-point numbers)
• Character strings
• Date and time
• Boolean values

More complex data types like images, audio, video, spatial data, and structured documents must be either:

• Stored as uninterpreted BLOBs (Binary Large Objects)
• Decomposed into multiple tables, complicating queries and updates
• Handled outside the DBMS

1.1.2 Complex Relationships

Relational databases struggle with certain types of relationships:

Hierarchical Relationships

• Parent-child relationships must be represented using foreign keys
• Complex hierarchies require recursive queries or additional tables

Many-to-Many Relationships

• Require intermediate junction tables
• Can be cumbersome to query and maintain

Inheritance Relationships

• No direct support for is-a relationships
• Typically implemented using one of several patterns:
  • Single table inheritance (all attributes in one table)
  • Table-per-class inheritance (separate tables, duplicate columns)
  • Table-per-concrete-class (separate tables for leaf classes)

1.1.3 Impedance Mismatch

The "impedance mismatch" refers to the conceptual gap between:

• Object-oriented programming models used in application development
• The relational model used in database systems

This mismatch requires translation between:

• Objects in memory (with methods, inheritance, and complex relationships)
• Relational tables (with rows, columns, and foreign keys)

This translation adds complexity and reduces performance:

• Developers must write code to map between objects and tables
• Performance is affected by the need to reconstruct objects from multiple tables

1.2 Beyond the Relational Model

To address these limitations, several approaches have evolved:

1.2.1 Object-Oriented Databases

Object-oriented databases extend database capabilities by directly supporting:

• Complex objects with methods and behaviors
• Inheritance hierarchies
• Polymorphism
• Direct representation of object relationships

Example:

CLASS Person {
    ATTRIBUTES:
        String name;
        Date birthDate;
        Address homeAddress;
    METHODS:
        int getAge();
        void setAddress(Address newAddress);
}

CLASS Employee EXTENDS Person {
    ATTRIBUTES:
        int employeeId;
        Date hireDate;
        Department dept;
    METHODS:
        float calculateSalary();
}

1.2.2 Object-Relational Databases

Object-relational databases combine features of both worlds:

• Maintain the foundation of the relational model (tables, SQL)
• Add support for objects, inheritance, and complex types
• Provide a more gradual transition path from relational systems

Example in SQL:1999 standard:

CREATE TYPE Address AS (
    street VARCHAR(100),
    city VARCHAR(50),
    state CHAR(2),
    zip VARCHAR(10)
);

CREATE TYPE Person AS (
    name VARCHAR(100),
    birthDate DATE,
    homeAddress Address,
    MEMBER FUNCTION getAge() RETURNS INTEGER
);

CREATE TABLE Employees OF Person (
    employeeId INTEGER PRIMARY KEY,
    hireDate DATE,
    department REF(Department)
) UNDER Person;

1.2.3 Semi-structured Data Models

Semi-structured data models like XML and JSON offer:

• Flexible schema (no predefined structure required)
• Hierarchical representation of data
• Self-describing data (includes both values and their meaning)
• Native support in many modern databases

Example in JSON:

{
  "person": {
    "name": "John Smith",
    "birthDate": "1985-05-15",
    "homeAddress": {
      "street": "123 Main St",
      "city": "Springfield",
      "state": "IL",
      "zip": "62701"
    },
    "type": "employee",
    "employeeId": 12345,
    "hireDate": "2010-03-01",
    "department": {
      "id": 42,
      "name": "Engineering"
    }
  }
}

1.3 Enhanced Entity-Relationship Model

The Enhanced Entity-Relationship (EER) model extends the basic ER model with additional semantic constructs to represent complex data more accurately.

1.3.1 Key Features of the EER Model

Subclass and Superclass

• Allows entities to be organized into hierarchies
• Subclasses inherit attributes from superclasses
• Enables representation of specialization and generalization

Attribute Inheritance

• Attributes defined for a superclass apply to all its subclasses
• Reduces redundancy in schema definition

Constraints on Specialization

• Total vs. partial specialization (must vs. may belong to subclass)
• Disjoint vs. overlapping subclasses (exclusive vs. multiple subclass membership)

Categories

• Represent union types (an entity belonging to one of several different entity types)
• Useful for modeling relationships involving entities from different hierarchies

1.3.2 EER Diagram Notation

EER diagrams extend ER diagram notation with:

• Double-lined rectangles for subclasses
• Lines with circle endpoints connecting to superclasses
• Annotations for constraints (d for disjoint, o for overlapping)
• Triangles to represent specialization/generalization relationships

Example:

┌───────────┐
│  Person   │◄───────────┐
└─────┬─────┘            │
      │                  │
      │ (d)              │
      ▼                  │
 ┌────┴─────┐      ┌─────┴────┐
 │ Employee │      │ Customer │
 └──────────┘      └──────────┘

2. Specialization and Generalization

Specialization and generalization are complementary processes that establish superclass-subclass relationships and form the foundation of inheritance hierarchies.

2.1 Specialization

Specialization is the process of defining subclasses from a superclass by identifying distinguishing characteristics.

2.1.1 Concept and Purpose

Specialization involves:

• Starting with a general entity type (superclass)
• Defining more specific entity types (subclasses)
• Identifying attributes unique to each subclass

Benefits include:

• More accurate representation of domain-specific entities
• Grouping of specialized attributes and relationships
• Supporting specialized operations on subclasses

Example: Starting with a general Vehicle superclass, we can specialize into Car, Truck, and Motorcycle subclasses, each with unique attributes.

2.1.2 Types of Specialization

Attribute-Defined Specialization

• Subclasses are defined based on the value of a discriminator attribute
• Example: Vehicle specializes into vehicle types based on the vehicleType attribute

User-Defined Specialization

• Subclasses are explicitly defined by the database designer
• Not based on any specific attribute value
• Example: Employee specializes into Manager, Engineer, and Technician based on job roles

2.1.3 Specialization Constraints

Disjointness Constraints

• Disjoint: An entity can belong to at most one subclass (exclusive)
• Overlapping: An entity can belong to multiple subclasses (non-exclusive)

Example:

• Disjoint: A vehicle must be either a car, a truck, or a motorcycle, but not multiple types
• Overlapping: A person can be both a student and an employee simultaneously

Completeness Constraints

• Total: Every superclass entity must belong to at least one subclass
• Partial: Some superclass entities may not belong to any subclass

Example:

• Total: Every vehicle must be categorized as either a car, a truck, or a motorcycle
• Partial: Some employees may not belong to any specialized category

2.2 Generalization

Generalization is the reverse process of specialization - identifying commonalities among entity types to define a more general superclass.

2.2.1 Concept and Purpose

Generalization involves:

• Starting with multiple entity types with common features
• Abstracting shared characteristics into a superclass
• Moving common attributes to the superclass

Benefits include:

• Reducing schema redundancy
• Centralizing common attribute definitions
• Facilitating code reuse in implementations

Example: Starting with Car, Truck, and Motorcycle entity types, we can identify common attributes like vehicleID, manufacturer, and year to create a more general Vehicle entity type.

2.2.2 Bottom-Up Design Process

The bottom-up generalization process typically follows these steps:

1. Identify similar entity types in the domain
2. Identify common attributes and relationships
3. Create a superclass containing these common elements
4. Remove the common attributes from the original entities
5. Establish subclass relationships with the new superclass

2.2.3 Multiple Inheritance

Multiple inheritance occurs when a subclass inherits from more than one superclass.

Benefits:

• Models complex real-world relationships
• Combines attributes and behaviors from different sources

Challenges:

• Name conflicts when superclasses have attributes with the same name
• Increased complexity in schema design and query processing

Example:

┌───────────┐     ┌───────────┐
│  Student  │     │ Employee  │
└─────┬─────┘     └─────┬─────┘
      │                 │
      └────────┬────────┘
               │
        ┌──────┴──────┐
        │ Student     │
        │ Assistant   │
        └─────────────┘

2.3 Implementation Approaches

Several approaches exist for implementing specialization/generalization relationships in database systems:

2.3.1 Single Table Inheritance

In this approach:

• All attributes from the superclass and all subclasses are stored in a single table
• A discriminator column indicates the specific subclass type
• Attributes not applicable to certain subclasses contain NULL values

Example:

CREATE TABLE Vehicle (
    vehicleID INT PRIMARY KEY,
    manufacturer VARCHAR(50),
    year INT,
    vehicleType VARCHAR(20),  -- Discriminator: 'Car', 'Truck', 'Motorcycle'
    numDoors INT,             -- Car-specific attribute
    cargoCapacity FLOAT,      -- Truck-specific attribute
    engineType VARCHAR(20)    -- Motorcycle-specific attribute
);

Advantages:

• Simple implementation
• Queries retrieving multiple subtypes are efficient (no joins)
• Easy to add or remove subtypes

Disadvantages:

• Many NULL values for inapplicable attributes
• Potentially large tables
• Cannot enforce subclass-specific constraints easily

2.3.2 Table Per Class Inheritance

In this approach:

• Each class in the hierarchy has its own table
• Each table contains both inherited and specific attributes
• Duplicate columns exist across tables

Example:

CREATE TABLE Vehicle (
    vehicleID INT PRIMARY KEY,
    manufacturer VARCHAR(50),
    year INT
);

CREATE TABLE Car (
    vehicleID INT PRIMARY KEY,
    manufacturer VARCHAR(50),
    year INT,
    numDoors INT
);

CREATE TABLE Truck (
    vehicleID INT PRIMARY KEY,
    manufacturer VARCHAR(50),
    year INT,
    cargoCapacity FLOAT
);

Advantages:

• Simple queries for specific subclasses
• No NULL values for inapplicable attributes

Disadvantages:

• Redundant storage of attributes
• Updates to superclass attributes must be propagated to all tables
• Queries across subtypes require UNION operations

2.3.3 Table Per Concrete Class Inheritance

In this approach:

• Only concrete classes (those that have instances) have tables
• Abstract superclass attributes are duplicated in each subclass table

Example:

CREATE TABLE Car (
    vehicleID INT PRIMARY KEY,
    manufacturer VARCHAR(50),  -- From Vehicle
    year INT,                  -- From Vehicle
    numDoors INT
);

CREATE TABLE Truck (
    vehicleID INT PRIMARY KEY,
    manufacturer VARCHAR(50),  -- From Vehicle
    year INT,                  -- From Vehicle
    cargoCapacity FLOAT
);

Advantages:

• No NULL values
• Queries for specific concrete classes are simple

Disadvantages:

• Redundant attribute definitions
• Complex queries across the entire hierarchy
• Cannot easily query based on superclass attributes only

2.3.4 Joined Table Inheritance

In this approach:

• Each class in the hierarchy has its own table
• Subclass tables contain only their specific attributes
• Foreign key relationships connect subclass tables to superclass tables

Example:

CREATE TABLE Vehicle (
    vehicleID INT PRIMARY KEY,
    manufacturer VARCHAR(50),
    year INT
);

CREATE TABLE Car (
    vehicleID INT PRIMARY KEY,
    numDoors INT,
    FOREIGN KEY (vehicleID) REFERENCES Vehicle(vehicleID)
);

CREATE TABLE Truck (
    vehicleID INT PRIMARY KEY,
    cargoCapacity FLOAT,
    FOREIGN KEY (vehicleID) REFERENCES Vehicle(vehicleID)
);

Advantages:

• No redundant attribute definitions
• No NULL values for inapplicable attributes
• Supports polymorphic associations

Disadvantages:

• Queries require joins
• Insert/update operations affect multiple tables
• Performance impact for deep hierarchies

3. Aggregation and Association

Aggregation and association represent different types of relationships between entities, providing ways to model complex structures and interactions.

3.1 Association

Association represents relationships between independent entity types.

3.1.1 Basic Association Concepts

An association:

• Connects two or more entity types
• Represents a relationship between instances of these types
• Has cardinality constraints (one-to-one, one-to-many, many-to-many)
• May have its own attributes

Example:

┌───────────┐    works_for    ┌───────────┐
│ Employee  │────────────────►│ Department│
└───────────┘                 └───────────┘

3.1.2 Association Attributes

Associations can have their own attributes that describe the relationship itself:

Example:

┌───────────┐                 ┌───────────┐
│ Student   │                 │ Course    │
└─────┬─────┘                 └─────┬─────┘
      │                             │
      │         enrolls_in          │
      └─────────────┬───────────────┘
                    │
             ┌──────┴──────┐
             │ grade       │
             │ date        │
             └─────────────┘

In SQL, an association with attributes is implemented using an intermediate table:

CREATE TABLE Enrollment (
    studentID INT,
    courseID INT,
    grade VARCHAR(2),
    enrollDate DATE,
    PRIMARY KEY (studentID, courseID),
    FOREIGN KEY (studentID) REFERENCES Student(studentID),
    FOREIGN KEY (courseID) REFERENCES Course(courseID)
);

3.1.3 Association Classes

In object-oriented modeling, association classes represent associations with attributes:

• Serve as both an association and a class
• Contain attributes specific to the relationship
• May have their own methods and behaviors

Example in UML notation:

Employee ──────────────── Project
             │
       ┌─────┴──────┐
       │ Assignment │
       ├────────────┤
       │ role       │
       │ startDate  │
       │ endDate    │
       └────────────┘

3.2 Aggregation

Aggregation represents a "part-of" relationship, where one entity is a component of another.

3.2.1 Basic Aggregation Concepts

Aggregation:

• Models "has-a" or "part-of" relationships
• Represents a hierarchy of components
• Maintains the identity of component objects
• Allows components to exist independently of the whole

Example:

┌───────────┐
│  Car      │
└─────┬─────┘
      ├──────────┐
┌─────▼────┐ ┌───▼─────┐
│  Engine  │ │  Wheel  │
└──────────┘ └─────────┘

3.2.2 Weak vs. Strong Aggregation

Weak Aggregation (Shared Aggregation)

• Component may be shared among multiple aggregates
• Component exists independently of the aggregate
• Deleting the aggregate doesn't necessarily delete the component

Strong Aggregation (Composition)

• Component belongs to exactly one aggregate
• Component's lifecycle is tied to the aggregate
• Deleting the aggregate typically deletes all its components

Example:

• Weak: A professor can be part of multiple departments
• Strong: A chapter is part of exactly one book and cannot exist without it

3.2.3 Implementing Aggregation

In relational databases, aggregation can be implemented in several ways:

Foreign Key References

CREATE TABLE Car (
    carID INT PRIMARY KEY,
    make VARCHAR(50),
    model VARCHAR(50)
);

CREATE TABLE Engine (
    engineID INT PRIMARY KEY,
    carID INT,
    horsepower INT,
    FOREIGN KEY (carID) REFERENCES Car(carID)
);

Embedded Complex Types (in object-relational databases)

CREATE TYPE EngineType AS (
    engineID INT,
    horsepower INT
);

CREATE TABLE Car (
    carID INT PRIMARY KEY,
    make VARCHAR(50),
    model VARCHAR(50),
    engine EngineType
);

3.3 Nested Relations

Nested relations allow for complex structures by embedding relations within relations.

3.3.1 Concept of Nested Relations

In nested relations:

• Attribute values can be relations themselves
• Relations can be nested to arbitrary depths
• Complex hierarchical structures can be represented naturally

Example:

EMPLOYEE(empID, name, 
    ADDRESS(street, city, state, zip),
    SKILLS(skillName, proficiencyLevel, yearAcquired)
)

3.3.2 Benefits and Challenges

Benefits:

• Natural representation of hierarchical data
• Reduced need for joins
• Encapsulates related data together

Challenges:

• More complex query processing
• Non-standard SQL extensions required
• Potential data redundancy

3.3.3 Nested Relations in Object-Relational Databases

Object-relational databases support nested relations through:

User-Defined Types and Collections

-- Define a structured type
CREATE TYPE Address AS (
    street VARCHAR(100),
    city VARCHAR(50),
    state CHAR(2),
    zip VARCHAR(10)
);

-- Define a collection type
CREATE TYPE SkillSet AS TABLE OF (
    skillName VARCHAR(50),
    proficiencyLevel INT,
    yearAcquired INT
);

-- Use these types in a table
CREATE TABLE Employee (
    empID INT PRIMARY KEY,
    name VARCHAR(100),
    homeAddress Address,
    skills SkillSet
);

Array Types

CREATE TABLE Employee (
    empID INT PRIMARY KEY,
    name VARCHAR(100),
    phoneNumbers VARCHAR(20) ARRAY[3],
    emailAddresses VARCHAR(100) ARRAY
);

4. Objects and Object Identity

Objects and object identity are fundamental concepts in object-oriented databases, providing a foundation for representing complex real-world entities.

4.1 Objects

Objects are the fundamental units in object-oriented databases, encapsulating both data and behavior.

4.1.1 Object Characteristics

An object typically has:

• State: Data stored in attributes/instance variables
• Behavior: Methods that operate on the state
• Identity: A unique identifier independent of state
• Encapsulation: Hides internal details, exposes interfaces

Example of an object:

Object: Employee_101
Attributes:
  - name: "John Smith"
  - birthDate: 1980-05-15
  - salary: 75000.00
Methods:
  - calculateBonus()
  - promote()
  - transfer(Department)

4.1.2 Object Types and Classes

In object-oriented databases:

• Class: Defines the structure (attributes and methods) shared by objects
• Object Type: Similar to a class but may lack some OO features in certain systems
• Instantiation: Process of creating objects from class definitions

Example:

CLASS Employee {
    ATTRIBUTES:
        String name;
        Date birthDate;
        Float salary;
    
    METHODS:
        Float calculateBonus();
        void promote();
        void transfer(Department dept);
}

// Creating an instance (object)
Employee emp1 = NEW Employee;
emp1.name = "John Smith";
emp1.birthDate = "1980-05-15";
emp1.salary = 75000.00;

4.1.3 Complex Objects

Complex objects include structures like:

Composite Objects

• Objects that contain other objects as components
• Example: A car object containing engine, wheels, and transmission objects

Collection Objects

• Sets, lists, arrays, or maps of other objects
• Example: A department containing a collection of employee objects

Example in an object-oriented database language:

CLASS Department {
    ATTRIBUTES:
        String name;
        Employee manager;
        SET<Employee> staff;
        MAP<String, Project> projects;
}

4.2 Object Identity

Object identity is a fundamental concept that distinguishes objects from one another, regardless of their content or state.

4.2.1 Concept of Object Identity

Object identity (OID):

• Uniquely identifies an object throughout its lifetime
• Is independent of the object's state
• Is immutable (doesn't change)
• Is system-generated (not visible to users)
• Persists across database sessions

Unlike traditional relational databases where identity is based on key values, object identity is intrinsic to the object itself.

4.2.2 Properties of Object Identifiers

Good object identifiers should be:

• Unique: No two objects share the same OID
• Immutable: The OID never changes during an object's lifetime
• Persistent: The OID remains the same across database sessions
• Location-independent: The OID doesn't depend on physical storage location
• System-generated: Created automatically by the DBMS

4.2.3 Types of Object Identifiers

Several approaches exist for implementing object identifiers:

Physical OIDs

• Based on physical storage location (e.g., disk address)
• Efficient for object access
• Problematic if objects are moved (requires forwarding address)

Logical OIDs

• Independent of physical storage
• Requires mapping to physical location
• More flexible but potentially less efficient

Surrogate OIDs

• System-generated unique values
• No semantic meaning
• Most common approach in commercial systems

Example implementation:

CREATE TABLE Employee (
    oid BIGINT PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
    name VARCHAR(100),
    birthDate DATE,
    salary DECIMAL(10,2)
);

4.3 Equality and Object Reference

Understanding the different concepts of equality is crucial in object-oriented database systems.

4.3.1 Types of Equality

Identity Equality

• Two variables reference the exact same object (same OID)
• Most restrictive form of equality
• Typically checked with special operators (e.g., "is" in Python, "===" in JavaScript)

Shallow Equality

• Objects have the same values for their attributes
• Doesn't compare nested objects deeply
• Like comparing the "top level" of objects

Deep Equality

• Recursively compares all nested objects
• Most comprehensive but potentially expensive
• Requires careful definition of comparison semantics

Example:

// Identity equality
IF (emp1 IS emp2) THEN ... // Same object

// Value equality
IF (emp1.name = emp2.name AND 
    emp1.birthDate = emp2.birthDate AND 
    emp1.salary = emp2.salary) THEN ... // Same content

4.3.2 Object References

Object references are pointers or handles to objects that:

• Allow objects to refer to other objects
• Enable construction of complex object networks
• Support relationship representation without duplication

Example:

CLASS Department {
    ATTRIBUTES:
        String name;
        Employee manager;  // Reference to an Employee object
}

Department engineering = NEW Department;
engineering.name = "Engineering";
engineering.manager = emp1;  // Reference to existing Employee object

4.3.3 Reference Types

Various types of references exist in object-oriented databases:

Strong References

• Normal references that prevent garbage collection
• Object remains in memory as long as reference exists

Weak References

• References that don't prevent garbage collection
• Used to avoid circular reference problems

Dangling References

• References to objects that no longer exist
• Potential source of errors if not handled properly

4.4 Object Reference Implementation

Object references can be implemented in several ways in database systems:

4.4.1 Direct References

Direct reference implementation:

• Stores the actual OID of the referenced object
• Provides fast access but limited flexibility
• Often implemented as a special reference type

Example in SQL:3 object-relational standard:

CREATE TYPE Department AS (
    deptID INTEGER,
    name VARCHAR(100)
);

CREATE TYPE Employee AS (
    empID INTEGER,
    name VARCHAR(100),
    department REF(Department)  -- Direct reference
);

4.4.2 Foreign Keys

Foreign key implementation:

• Traditional approach in relational databases
• Stores key values rather than OIDs
• May require additional joins for access

Example:

CREATE TABLE Department (
    deptID INTEGER PRIMARY KEY,
    name VARCHAR(100)
);

CREATE TABLE Employee (
    empID INTEGER PRIMARY KEY,
    name VARCHAR(100),
    deptID INTEGER,
    FOREIGN KEY (deptID) REFERENCES Department(deptID)
);

4.4.3 Path Expressions

Path expressions allow navigation of object references in queries:

• Provide a notation for traversing object relationships
• Simplify queries involving multiple related objects

Example:

-- Using path expressions in object-relational SQL
SELECT e.name, e.department->name
FROM Employee e
WHERE e.department->name = 'Engineering';

-- Equivalent in relational SQL would require a join
SELECT e.name, d.name
FROM Employee e JOIN Department d ON e.deptID = d.deptID
WHERE d.name = 'Engineering';

5. Architecture of Object-Oriented and Object-Relational Databases

The architecture of object-oriented and object-relational database systems reflects their focus on handling complex objects and relationships.

5.1 Object-Oriented Database Architecture

Object-oriented database systems (OODBMS) are designed to manage objects that encapsulate both data and behavior.

5.1.1 Core Components

An OODBMS typically includes:

Object Manager

• Creates and maintains objects
• Manages object identity
• Implements inheritance and polymorphism

Method Executor

• Invokes methods on objects
• Manages method execution context

Storage Manager

• Maps objects to physical storage
• Handles object clustering and pages
• Manages indexes for efficient access

Transaction Manager

• Ensures ACID properties for transactions
• Provides concurrency control
• Handles recovery after failures

Query Processor

• Parses and optimizes object queries
• Translates queries to execution plans
• Interfaces with the object manager for retrieval

5.1.2 Architectural Approaches

Different architectural approaches exist for OODBMS:

Integrated Architecture

• Built from the ground up as an object-oriented system
• Native support for objects, methods, and inheritance
• Examples: ObjectStore, Versant

Layered Architecture

• Object-oriented layer built on top of another storage system
• May use a relational engine underneath
• Examples: Some configurations of ObjectDB

Client-Server Architecture

• Object server manages persistent storage
• Clients execute methods and manipulate objects locally
• Objects transferred between client and server as needed

5.1.3 Object Persistence Mechanisms

OODBMS provide various persistence mechanisms:

Explicit Persistence

• Objects are explicitly made persistent by programmer action
• Example: db.store(myObject);

Persistence by Reachability

• Objects referenced by persistent roots are automatically persistent
• Creates a "persistence closure"
• Example: GemStone/S approach

Class-Based Persistence

• Instances of designated persistent classes are automatically saved
• Simplifies programming but less flexible

5.2 Object-Relational Database Architecture

Object-relational database systems (ORDBMS) extend relational technology with object-oriented features.

5.2.1 Core Components

An ORDBMS typically includes traditional RDBMS components plus:

Type System Manager

• Manages user-defined types
• Handles type inheritance
• Maps complex types to storage

Method Manager

• Stores and executes user-defined functions and methods
• Manages function overloading and resolution

Extended Query Processor

• Handles enhanced SQL with object extensions
• Processes path expressions and method invocations
• Optimizes queries involving complex objects

Object-Relational Storage Engine

• Stores structured and complex attributes
• Manages collections and nested structures
• Handles large objects (BLOBs and CLOBs)

5.2.2 Architectural Approaches

Different architectural approaches exist for ORDBMS:

Extended Relational Architecture

• Core relational engine with object extensions
• SQL interface enhanced with object features
• Examples: Oracle, PostgreSQL

Dual-Model Architecture

• Separate subsystems for relational and object data
• Integrated query facilities
• Examples: Some versions of Informix Universal Server

Hybrid Architecture

• Blends relational and object-oriented concepts
• Uniform treatment of tables and object types
• Example: IBM DB2's approach

5.2.3 Extensibility Mechanisms

ORDBMS provide various extensibility mechanisms:

User-Defined Types (UDTs)

• Allow definition of complex structured types
• Support for custom methods on types
• Example:

  CREATE TYPE Address AS (
      street VARCHAR(100),
      city VARCHAR(50),
      state CHAR(2),
      zip VARCHAR(10),
      MEMBER FUNCTION getFullAddress() RETURNS VARCHAR(200)
  );
  

User-Defined Functions (UDFs)

• Extend SQL with custom functions
• Can be written in SQL or external languages
• Example:

  CREATE FUNCTION calculateAge(birthDate DATE)
  RETURNS INTEGER
  LANGUAGE SQL
  RETURN YEAR(CURRENT_DATE) - YEAR(birthDate) - 
         CASE WHEN MONTH(CURRENT_DATE) < MONTH(birthDate) OR 
              (MONTH(CURRENT_DATE) = MONTH(birthDate) AND 
               DAY(CURRENT_DATE) < DAY(birthDate))
              THEN 1 ELSE 0 END;
  

Table Inheritance

• Enables table hierarchies that mirror type hierarchies
• Supports polymorphic queries
• Example:

  CREATE TABLE Person (
      personID INTEGER PRIMARY KEY,
      name VARCHAR(100),
      birthDate DATE
  );
  
  CREATE TABLE Employee UNDER Person (
      employeeID INTEGER,
      hireDate DATE,
      salary DECIMAL(10,2)
  );
  

5.3 Comparison of Architectures

Object-oriented and object-relational databases differ in several key aspects:

5.3.1 Object Model Integration

OODBMS

• Complete integration with object-oriented programming
• Seamless mapping between database and programming language objects
• Direct support for inheritance, polymorphism, and encapsulation

ORDBMS

• Partial integration with object-oriented concepts
• SQL-based interface with object extensions
• Type system may differ from programming language types

5.3.2 Query Language Approach

OODBMS

• Object query languages (OQL) or language-integrated queries
• Navigate through object relationships
• Method invocation within queries
• Example:

  SELECT e.name, e.department.name
  FROM Employees e
  WHERE e.salary > 50000 AND e.calculateBonus() > 5000
  

ORDBMS

• Extended SQL with object features
• Maintain SQL's declarative nature
• Support for path expressions and method calls in SQL
• Example:

  SELECT e.name, e.department->name
  FROM Employee e
  WHERE e.salary > 50000 AND calculate_bonus(e) > 5000
  

5.3.3 Performance Characteristics

OODBMS

• Optimized for navigational access through objects
• Efficient for complex object networks
• May struggle with ad hoc queries and reports
• Better performance with object-centric operations

ORDBMS

• Optimized for set-based operations
• Efficient for ad hoc queries and reports
• May have overhead for simple object navigation
• Better for mixed relational and object workloads

5.3.4 Application Integration

OODBMS

• Tightly integrated with specific programming languages
• Minimal "impedance mismatch"
• Strong support for persistent programming languages
• Examples: Java with ObjectDB, Smalltalk with GemStone/S

ORDBMS

• Language-neutral with SQL interface
• Supporting tools and drivers for many languages
• Some impedance mismatch remains
• Wide industry adoption and standards

5.4 Commercial and Open Source Implementations

Various implementations of object-oriented and object-relational databases are available:

5.4.1 Object-Oriented Database Systems

Commercial OODBMS

• ObjectStore: High-performance OODBMS with C++ and Java bindings
• Versant Object Database: Enterprise-scale OODBMS
• GemStone/S: Smalltalk-based distributed object database

Open Source OODBMS

• ObjectDB: Pure Java object database
• db4o: Embeddable object database for Java and .NET
• ZODB: Python object database

5.4.2 Object-Relational Database Systems

Commercial ORDBMS

• Oracle Database: Extensive object-relational features
• IBM DB2: Object-relational capabilities with SQL extensions
• Microsoft SQL Server: Some object-relational features

Open Source ORDBMS

• PostgreSQL: Robust object-relational features including table inheritance
• MySQL: Limited object-relational capabilities
• Firebird: Open source with some object-relational features

5.4.3 Industry Trends

Current trends in the database industry related to object-oriented and object-relational technologies:

NoSQL Movement

• Document databases store complex objects as JSON
• Graph databases focus on complex relationships
• Key-value stores offer simple object storage

Hybrid Systems

• Combining relational, object, and NoSQL approaches
• Multi-model databases supporting different data paradigms
• Polyglot persistence using specialized systems for different needs

Object-Relational Mapping (ORM)

• Middleware solutions bridging object and relational worlds
• Examples: Hibernate, Entity Framework, Django ORM
• Address impedance mismatch at the application level

This concludes our comprehensive examination of object-oriented and object-relational databases. Understanding these concepts enables the design and implementation of database systems that effectively handle complex data types and relationships required by modern applications.

These notes were compiled by Deepak Modi
Visit NotesNeo for more resources.
Last updated: June 2025