OODBMS Languages & Design: Queries, Methods, and Schemas

TAKEAWAYS:

• OODBMS languages (e.g., OQL) extend SQL with object-oriented features like methods, polymorphism, and nested queries.
• Schema design in OODBMS uses classes, inheritance, and encapsulation to model real-world entities (e.g., User, Order, Product in eSewa).
• Methods (e.g., calculateTotal()) are stored in the database, enabling behavioral queries (e.g., order.total() in Daraz).
• Advantages: Efficient for hierarchical data (e.g., NEPSE stock hierarchies), but disadvantages include limited standardization and tool support.
• Design principles: Avoid tight coupling (e.g., Daraz’s order-processing system) and use abstraction (e.g., Ncell’s billing abstraction).
• Exam focus: Compare OODBMS vs. RDBMS, trace OQL queries, and design schemas for given scenarios (e.g., a bank’s loan system).

1. Introduction to OODBMS Languages

OODBMS languages (e.g., Object Query Language (OQL)) blend SQL’s declarative power with object-oriented features like methods, polymorphism, and encapsulation. Unlike SQL, which focuses on tables and rows, OODBMS languages treat data as objects with identity, state, and behavior.

Key Features of OODBMS Languages

Why OQL?

• Methods as queries: In eSewa, a method like user.getTransactionHistory() directly accesses nested objects without complex JOINs.
• Polymorphism: A Payment class can have subclasses (KhaltiPayment, BankPayment) with shared and overridden methods.

2. OQL: The Query Language for OODBMS

OQL extends SQL with object-oriented constructs. Below is a breakdown of its syntax and use cases.

Basic OQL Syntax

-- Select objects with conditions
SELECT o FROM Order o WHERE o.status = "Shipped"

-- Nested queries (like SQL subqueries)
SELECT p FROM Product p WHERE p.price > (SELECT AVG(price) FROM Product)

-- Method invocation (behavioral queries)
SELECT o.total() FROM Order o WHERE o.customer.id = 101

-- Path expressions (navigation)
SELECT u.orders FROM User u WHERE u.name = "Rohan"

Worked Example: NEPSE Stock Data

Assume NEPSE stores stock data as objects with methods:

classDiagram
    class Stock {
        +String symbol
        +float price
        +calculateDailyChange() float
    }
    class User {
        +String name
        +List~Stock~ portfolio
        +getTotalInvestment() float
    }
    User "1" --> "0..*" Stock : holds

Query: Find all users with a total investment > Rs. 500,000.

SELECT u FROM User u WHERE u.getTotalInvestment() > 500000

Real-world tie: NEPSE’s backend likely uses OODBMS to model stocks, users, and transactions with methods like Stock.updatePrice() and User.executeTrade().

3. Schema Design in OODBMS

Schema design in OODBMS focuses on classes, inheritance, and relationships, unlike RDBMS’s tables and foreign keys.

Design Principles

1. Encapsulation: Bundle data (attributes) and behavior (methods) in a class.
   • Example: A BankAccount class encapsulates balance and withdraw().
2. Inheritance: Model "is-a" relationships (e.g., SavingsAccount inherits from BankAccount).
3. Aggregation/Composition: Model "has-a" relationships (e.g., Order has OrderItems).
4. Abstraction: Hide complex logic (e.g., PaymentGateway.process() in Daraz).

Example: Daraz Order System

Key Methods:

• Order.calculateTotalTax(): Computes tax based on OrderItem.subtotal().
• Product.applyDiscount(): Updates price dynamically.

Advantages:

• Efficiency: Avoids JOINs for nested data (e.g., order.items).
• Extensibility: New product types (e.g., DigitalProduct) inherit from Product.

Disadvantages:

• Tooling: Limited compared to SQL (e.g., no standard OODBMS IDEs like MySQL Workbench).
• Learning Curve: Requires OOP knowledge.

4. Comparing OODBMS and RDBMS

When to Use OODBMS?

• Complex hierarchies: eSewa’s nested transaction data.
• Behavioral queries: Ncell’s billing system with Bill.calculateDueDate().
• Performance: Avoiding JOINs for deeply nested data (e.g., Daraz’s order history).

When to Use RDBMS?

• Simple CRUD: Bank account transactions.
• Standardization: Widely supported tools (e.g., PostgreSQL).

5. Real-World Applications

In the Real World

1. eSewa (Nepal)

   • Idea Used: OODBMS schema design for nested transactions.
   • How: Models User, Transaction, and PaymentMethod with inheritance (e.g., KhaltiPayment extends Payment).
   • Method Example: Transaction.verify() checks nested Payment objects.

2. Google’s Bigtable

   • Idea Used: OODBMS for hierarchical data (e.g., YouTube comments).
   • How: Stores comments as objects with parentComment references, enabling comment.getReplies().

3. NEPSE Stock Exchange

   • Idea Used: OQL for behavioral queries.
   • How: Queries like SELECT s FROM Stock s WHERE s.price > s.avgPrice() use methods like Stock.avgPrice().

4. Pathao’s Ride System

   • Idea Used: Aggregation in OODBMS.
   • How: An Order object contains OrderItems (e.g., Ride, Delivery), with methods like Order.calculateEta().

6. Worked Example: Bank Loan System

Scenario: Design an OODBMS schema for a bank’s loan system with:

• Loan (loanId, amount, interestRate)
• Customer (name, loans)
• LoanType (e.g., HomeLoan, CarLoan) inheriting from Loan.

Schema:

OQL Query: Find all customers with a loan payment > Rs. 20,000.

SELECT c FROM Customer c
WHERE c.loans.any(l | l.calculateMonthlyPayment() > 20000)

Real-world tie: Nepal’s banks (e.g., NMB) use similar systems to compute EMI (Equated Monthly Installment) dynamically.

7. Common Pitfalls and Best Practices

Pitfalls

1. Overusing Inheritance: Can lead to rigid schemas (e.g., adding a new LoanType requires schema changes).
2. Ignoring Performance: Deep object graphs slow queries (e.g., user.orders.items.product in Daraz).
3. Lack of Standards: OQL is not as mature as SQL; tooling may be limited.

Best Practices

1. Use Abstraction: Hide complex logic in methods (e.g., Payment.process()).
2. Denormalize Strategically: Duplicate data to avoid JOINs (e.g., store customer.name in Loan).
3. Leverage Aggregation: Model "has-a" relationships explicitly (e.g., Order contains OrderItem).

Exam Tip

1. Compare OODBMS vs. RDBMS: Expect questions on when to use each (e.g., "Design a schema for NEPSE’s stock data—choose OODBMS or RDBMS and justify").
2. Trace OQL Queries: Given a class diagram, write OQL queries (e.g., "Find all orders with items priced > Rs. 500").
3. Design Schemas: Draw class diagrams for scenarios (e.g., "Design an OODBMS for a hospital’s patient records").
4. Method Invocation: Recognize behavioral queries (e.g., order.calculateTax() vs. SQL’s SELECT SUM(tax)).
5. Real-world Mapping: Relate examples to apps like eSewa or Daraz (e.g., "How would you model eSewa’s transaction hierarchy?").

Common Exam Questions:

• "Write an OQL query to find all users with orders totaling > Rs. 10,000."
• "Compare the schema design of a bank’s loan system in OODBMS vs. RDBMS."
• "Explain how Pathao’s ride system uses aggregation in OODBMS."