Quartz 4

OODBMS short notes

3 min read

2.1 Motivation

  • Why OODBMS? Relational DBMS (RDBMS) limitations:
    • Struggle with complex apps (CAD, GIS, Multimedia).
    • Limited type system (can’t add new types easily).
    • 1NF restriction (no collections/nested objects in columns).
  • OODBMS needed for these complex applications & data types.

2.2 Concept & Features

  • Core Idea: Combines DBMS Features (persistence, concurrency, recovery, query) + OO Features.
  • No single initial spec; “Manifesto” (1989) defined key features.

2.2.1 Mandatory OO Features

  1. Complex Objects: Non-1NF; attributes can be objects or collections (lists, sets, bags).
  2. Object Identity (OID): Unique, system-generated ID for each object. Independent of attribute values. Persists for object lifetime.
  3. Encapsulation: Data (attributes) + method implementation hidden. Access only via public object Methods (interface).
  4. Types/Classes: Template for objects. Groups objects with same structure (attributes) & behavior (methods).
  5. Inheritance: Class hierarchies (is_a). Subclass inherits attributes/methods from superclass. Promotes reuse.
  6. Polymorphism (Overriding, Late Binding):
    • Overriding: Subclass provides own method implementation.
    • Late Binding: Method code chosen at runtime based on object’s actual class.
    • (Overloading: Same method name, different parameters - less emphasized for OODBMS core idea).
  7. Computational Completeness: DML is a full programming language (C++, Java). Avoids impedance mismatch (SQL vs. host language in RDBMS).
  8. Extensibility: User-defined types treated same as built-in types.

2.2.2 Mandatory DB Features

  • Standard DBMS stuff, but for objects:
    • Persistence: Objects survive program termination (stored on disk).
    • Secondary Storage Mgmt: Efficient handling of large data on disk (indexing, caching) - transparent to user.
    • Concurrency: Control simultaneous user access (e.g., locking).
    • Recovery: Restore DB state after failures (e.g., logging).
    • Ad hoc Query: High-level way to query data (not necessarily SQL).
  • Standard: ODMG tried to create one.

2.3 Making OOPL a Database

  • Approach: Add DB features (persistence, etc.) to objects in an OOPL (C++, Java).
  • How: Extend OOPL (e.g., Persistent Class keyword).
  • Advanced Features: Often needed: Fast navigation (pointer chasing), versions, long transactions, schema evolution.

2.3.1 Object Data Modeling

  • Object = Structure (Attributes, Relationships) + Behavior (Methods).
  • Attributes: Can be simple or complex types (references to other objects, collections).
  • Relationships: Associations between objects (e.g., publishedBy, writtenBy). Often implemented using reference attributes. Cardinality (1:1, 1:N, N:M). Aggregation (composedOf).
  • Inheritance: Models is_a (e.g., ArtBook is_a Book).
  • Message: Request sent to an object to execute a method.
  • Method: Code implementing object behavior (responds to messages).

2.3.2 Persistence of Objects

  • How made persistent?
    1. Explicit call per object (e.g., myBook.persist()).
    2. Declare class as persistent (all instances are auto-persistent).
  • Goal: Seamless integration, unified language avoids impedance mismatch.

2.4 GemStone (Example OODBMS)

  • Basics: Early commercial OODBMS, Smalltalk-based. OPAL language.
  • Architecture (Client/Server):
    • Stone (Server): Core DB engine (disk IO, concurrency, recovery, OID management).
    • Gem (Client/App Server): User interaction (compilation, browsing, auth).
  • Object Model (Smalltalk-like):
    • Everything is an Object. Persistent by default.
    • Class: Template.
    • Message: Communication → triggers Method. Enforces encapsulation.
  • Collections: Objects to group other objects (built-in classes).
    • Array: Ordered, indexed.
    • Bag: Unordered, duplicates allowed.
    • Set: Unordered, duplicates not allowed.

2.5 Comparisons OODBS & RDBMS

  • Correspondence (Approximate Only!):
    • Object ≈ Tuple/Row
    • Class ≈ Table/Relation (+ behavior)
    • Instance Variable ≈ Attribute/Column
    • OID ≈ Primary Key
    • Method ≈ Stored Procedure (but integrated differently)
  • OODBMS Advantages:
    • Better for complex objects/relationships.
    • Inheritance (reuse, natural modeling).
    • No impedance mismatch.
    • Fast navigational access.
  • OODBMS Disadvantages:
    • Weaker query standards (vs. SQL).
    • Less mature ad-hoc query tools.
    • Schema evolution can be complex.
    • Often tied to one language.
  • Trend: Object-Relational DBMS (ORDBMS) blend features. OODBMS for specialized apps.

Graph View

Backlinks