Quick Review

GemStone Architecture: Quick Notes

1. Model: Client-Server OODBMS.
2. Core Processes:
   • Stone (Server):
     • Role: Database Engine Core.
     • Runs: On Server Machine.
     • Manages: Disk I/O, Concurrency, Recovery, Authorization, Object Table (maps OOPs to disk).
   • Gem (Client/Server):
     • Role: Application Interface / Frontend.
     • Runs: Client or Server Machine.
     • Handles: Compilation, Browsing, Authentication, App Logic Execution.
     • Communicates with Stone to get/store objects.
3. Object Handling:
   • Persistence: All objects are persistent (managed by Stone).
   • Identification: Uses OOPs (Object-Oriented Pointers) - unique logical IDs.
   • Mapping: Stone’s Object Table links OOPs to physical object locations (disk/memory). This allows objects to move without breaking references.

TP-Monitor Architectures: Quick Review Notes

Overall Goal: Handle high-volume transactions efficiently, reliably, and consistently in a client-server setup.

Four Models (Progression):

1. Process-per-Client Model:

   • Idea: One dedicated server process for each client.
   • Pros: Simple concept.
   • Cons:
     • HUGE Memory Use: Each process needs its own memory.
     • SLOW Context Switching: OS switching between processes is expensive (hundreds of µs). Inefficient for many clients

2. Single-Server Model:

   • Idea: One single server process for all clients.
   • Key Tech: Uses multithreading within the server process.
   • Pros:
     • Less memory than Model 1.
     • FAST Context Switching: Switching between threads is cheap (µs).
   • Cons:
     • No Protection: One bad app/thread can crash the entire server.
     • Poor Scalability: Doesn’t easily scale across multiple machines (parallel/distributed DBs).
   • Examples: Old CICS, NetWare.

3. Many-Server, Single-Router Model:

   • Idea: Multiple server processes, one router process directs client requests.
   • Key Features:
     • Router distributes load.
     • Can have pools of servers per application.
     • Servers can still be multithreaded.
   • Pros:
     • Better scalability (servers on different machines).
     • Supports multiple applications distinctly.
     • Load balancing possible via router/pools.
     • Better protection between server processes.

4. Many-Server, Many-Router Model:

   • Idea: Multiple routers, multiple servers. A controller oversees.
   • Key Features: Multiple entry points (routers).
   • Pros:
     • Highest Scalability: Handles massive client/server numbers.
     • Highest Availability: Failure of one router isn’t catastrophic.

**TP Monitor Components

• Core Idea: Manages the lifecycle of a transaction request from client to database and back.

• Key Components & Flow:

  1. Input Queue:
     • Receives incoming client requests.
     • Can be Durable: Survives crashes, ensuring requests aren’t lost.
  2. Authorization:
     • Checks user identity and permissions.
  3. Application Server Management:
     • Starts/Manages application server processes/threads.
     • Routes requests to the correct/available server (handles pools).
  4. Core Transaction Managers: (Work together)
     • Lock Manager: Handles concurrency control (locking resources).
     • Log Manager: Writes to the transaction log (essential for recovery).
     • Recovery Manager: Uses the log to handle failures (rollback/rollforward).
  5. Database & Resource Managers:
     • Provides the interface for application servers to access the database and other resources (files, etc.).
  6. Output Queue:
     • Holds outgoing responses back to the client.

10) Explain how query languages (like OQL - Object Query Language) are used in object-oriented databases. How do they differ from SQL queries?

OODB Query Languages (QLs) - How Used:

• Integrated: Built into the programming language (C++/Java).
• Same Types: Uses the language’s type system (no conversion needed).
• Direct: Manipulate persistent objects directly (no explicit fetch/store code).
• Collections: Query class extents (all objects of a class) using iterators & filters.
• Complex: Specific QLs exist for queries beyond simple iteration (though OQL details weren’t in the text).

Key Differences: OODB QL vs. SQL:

• Focus:
  • OODB: Objects, Classes, References (Pointers).
  • SQL: Tables, Rows, Columns, Joins.
• Integration:
  • OODB: Tight with host language, same types.
  • SQL: Separate language, different types, needs conversion.
• Access:
  • OODB: Transparent persistence (looks like normal objects).
  • SQL: Explicit commands (SELECT, INSERT, etc.).
• Style:
  • OODB: Less declarative, often navigational (follow pointers), iterates.
  • SQL: Declarative (specify what, not how), optimizer plans execution.
• Goals:
  • OODB: High performance, seamless OOP integration, complex object handling.
  • SQL: Powerful/flexible querying, data independence, protection.

Core Trade-off: OODB QLs (in persistent languages) prioritize integration/performance. SQL prioritizes declarative power/independence.

9) Design a class hierarchy for a University Database (Student, Teacher, Course, Department) using object-oriented concepts. How would you model this in an OODBMS?

Person
  |-- name (structured type or varchar)
  |-- address (structured type or varchar)
  |-- personID (Persistent Identifier)
  |
  |--- Student (under Person)
  |      |-- Inherits: name, address, personID
  |      |-- studentID (specific identifier)
  |      |-- degreeProgram
  |      |-- major (ref to Department)
  |      |-- coursesTaken (collection of ref to Course)
  |
  |--- Teacher (under Person)
         |-- Inherits: name, address, personID
         |-- teacherID (specific identifier)
         |-- salary
         |-- rank
         |-- department (ref to Department)
         |-- coursesTaught (collection of ref to Course)
 
Department
  |-- deptID (Persistent Identifier)
  |-- deptName
  |-- head (ref to Teacher)
  |-- faculty (collection of ref to Teacher)
  |-- coursesOffered (collection of ref to Course)
 
Course
  |-- courseID (Persistent Identifier)
  |-- courseName
  |-- credits
  |-- department (ref to Department)
  |-- instructor (ref to Teacher)
  |-- enrolledStudents (collection of ref to Student)

 
CREATE TYPE Person (
    personID INTEGER, -- Or use system generated refs later
    name VARCHAR(50), -- Could be a structured type like 'Name' if defined
    address VARCHAR(100) -- Could be a structured type like 'Address' if defined
) NOT FINAL; -- Allows subtypes (Student, Teacher)
 
CREATE TYPE Department (
    deptID VARCHAR(10) PRIMARY KEY, -- Assuming a simple key for simplicity
    deptName VARCHAR(50),
    head REF(Teacher) -- Reference to a Teacher object
    -- Scope would be defined on the table if using O-R mapping
);
 
CREATE TYPE Course (
    courseID VARCHAR(10) PRIMARY KEY, -- Assuming a simple key
    courseName VARCHAR(50),
    credits INTEGER,
    department REF(Department) -- Reference to the offering Department
);
 
-- Define Subtypes using Inheritance (Student, Teacher)
 
CREATE TYPE Student UNDER Person (
    studentID VARCHAR(10) PRIMARY KEY, -- Specific ID for Student
    degreeProgram VARCHAR(50),
    major REF(Department), -- Reference to the Student's major Department
    coursesTaken MULTISET(REF(Course)) -- Collection of references to Courses
);
 
CREATE TYPE Teacher UNDER Person (
    teacherID VARCHAR(10) PRIMARY KEY, -- Specific ID for Teacher
    salary INTEGER,
    rank VARCHAR(20),
    department REF(Department), -- Reference to the Teacher's Department
    coursesTaught MULTISET(REF(Course)) -- Collection of references to Courses
);
 

d