ObjectOriented DBMSs

1
Object-Oriented DBMSs

• Source Database Systems by Connolly Begg

2
Commercial OODBMSs

• GemStone from Gemstone Systems Inc.,
• Itasca from Ibex Knowledge Systems SA,
• Objectivity/DB from Objectivity Inc.,
• ObjectStore from eXcelon Corp.,
• Ontos from Ontos Inc.,
• Poet from Poet Software Corp.,
• Jasmine from Computer Associates/Fujitsu,
• Versant from Versant Object Technology.

3
Origins of the Object-Oriented Data Model
4
Persistent Programming Languages (PPLs)

• Language that provides users with ability to
  (transparently) preserve data across successive
  executions of a program, and even allows such
  data to be used by many different programs.
• In contrast, database programming language (e.g.
  SQL) differs by its incorporation of features
  beyond persistence, such as transaction
  management, concurrency control, and recovery.

5
Persistent Programming Languages (PPLs)

• PPLs eliminate impedance mismatch by extending
  programming language with database capabilities.
• In PPL, languages type system provides data
  model, containing rich structuring mechanisms.
• In some PPLs procedures are first class objects
  and are treated like any other object in
  language.
• Procedures are assignable, may be result of
  expressions, other procedures or blocks, and may
  be elements of constructor types.
• Procedures can be used to implement ADTs.

6
Persistent Programming Languages (PPLs)

• PPL also maintains same data representation in
  memory as in persistent store.
• Overcomes difficulty and overhead of mapping
  between the two representations.
• Addition of (transparent) persistence into a PPL
  is important enhancement to IDE, and integration
  of two paradigms provides more functionality and
  semantics.

7
Alternative Strategies for Developing an OODBMS

• Extend existing object-oriented programming
  language.
• GemStone extended Smalltalk.
• Provide extensible OODBMS library.
• Approach taken by Ontos, Versant, and
  ObjectStore.
• Embed OODB language constructs in a conventional
  host language.
• Approach taken by O2,which has extensions for C.

8
Alternative Strategies for Developing an OODBMS

• Extend existing database language with
  object-oriented capabilities.
• Approach being pursued by RDBMS and OODBMS
  vendors.
• Ontos and Versant provide a version of OSQL.
• Develop a novel database data model/language.

9
Single-Level v. Two-Level Storage Model

• Traditional programming languages lack built-in
  support for many database features.
• Increasing number of applications now require
  functionality from both database systems and
  programming languages.
• Such applications need to store and retrieve
  large amounts of shared, structured data.

10
Single-Level v. Two-Level Storage Model

• With a traditional DBMS, programmer has to
• Decide when to read and update objects.
• Write code to translate between applications
  object model and the data model of the DBMS.
• Perform additional type-checking when object is
  read back from database, to guarantee object will
  conform to its original type.

11
Single-Level v. Two-Level Storage Model

• Difficulties occur because conventional DBMSs
  have two-level storage model storage model in
  memory, and database storage model on disk.
• In contrast, OODBMS gives illusion of
  single-level storage model, with similar
  representation in both memory and in database
  stored on disk.
• Requires clever management of representation of
  objects in memory and on disk (called pointer
  swizzling).

12
Two-Level Storage Model for RDBMS
13
Single-Level Storage Model for OODBMS
14
Pointer Swizzling Techniques

• The action of converting object identifiers
  (OIDs) to main memory pointers.
• Aim is to optimize access to objects.
• Should be able to locate any referenced objects
  on secondary storage using their OIDs.
• Once objects have been read into cache, want to
  record that objects are now in memory to prevent
  them from being retrieved again.

15
Pointer Swizzling Techniques

• Could hold lookup table that maps OIDs to memory
  pointers.
• Pointer swizzling attempts to provide a more
  efficient strategy by storing memory pointers in
  the place of referenced OIDs, and vice versa when
  the object is written back to disk.

16
No Swizzling

• Easiest implementation is not to do any
  swizzling.
• Objects faulted into memory, and handle passed to
  application containing objects OID.
• OID is used every time the object is accessed.
• System must maintain some type of lookup table so
  that objects virtual memory pointer can be
  located and then used to access object.
• Inefficient if same objects are accessed
  repeatedly.
• Acceptable if objects only accessed once.

17
Object Referencing

• Need to distinguish between resident and
  non-resident objects.
• Most techniques variations of edge marking or
  node marking.
• Edge marking marks every object pointer with a
  tag bit
• if bit set, reference is to memory pointer
• else, still pointing to OID and needs to be
  swizzled when object it refers to is faulted
  into.

18
Object Referencing

• Node marking requires that all object references
  are immediately converted to virtual memory
  pointers when object is faulted into memory.
• First approach is software-based technique but
  second can be implemented using software or
  hardware-based techniques.

19
Hardware-Based Schemes

• Use virtual memory access protection violations
  to detect accesses of non-resident objects.
• Use standard virtual memory hardware to trigger
  transfer of persistent data from disk to memory.
• Once page has been faulted in, objects are
  accessed via normal virtual memory pointers and
  no further object residency checking is required.
  
• Avoids overhead of residency checks incurred by
  software approaches.

20
Pointer Swizzling - Other Issues

• Three other issues that affect swizzling
  techniques
• Copy versus In-Place Swizzling.
• Eager versus Lazy Swizzling.
• Direct versus Indirect Swizzling.

21
Copy versus In-Place Swizzling

• When faulting objects in, data can either be
  copied into applications local object cache or
  accessed in-place within object managers
  database cache .
• Copy swizzling may be more efficient as, in the
  worst case, only modified objects have to be
  swizzled back to their OIDs.
• In-place may have to unswizzle entire page of
  objects if one object on page is modified.

22
Eager versus Lazy Swizzling

• Moss defines eager swizzling as swizzling all
  OIDs for persistent objects on all data pages
  used by application, before any object can be
  accessed.
• More relaxed definition restricts swizzling to
  all persistent OIDs within object the application
  wishes to access.
• Lazy swizzling only swizzles pointers as they are
  accessed or discovered.

23
Direct versus Indirect Swizzling

• Only an issue when swizzled pointer can refer to
  object that is no longer in virtual memory.
• With direct swizzling, virtual memory pointer of
  referenced object is placed directly in swizzled
  pointer.
• With indirect swizzling, virtual memory pointer
  is placed in an intermediate object, which acts
  as a placeholder for the actual object.
• Allows objects to be uncached without requiring
  swizzled pointers to be unswizzled.

24
Accessing an Object with a RDBMS
25
Accessing an Object with an OODBMS
26
Versions

• Allows changes to properties of objects to be
  managed so that object references always point to
  correct object version.
• Itasca identifies 3 types of versions
• Transient Versions.
• Working Versions.
• Released Versions.

27
Versions and Configurations
28
Versions and Configurations
29
Schema Evolution

• Some applications require considerable
  flexibility in dynamically defining and modifying
  database schema.
• Typical schema changes
• (1) Changes to class definition
• (a) Modifying Attributes.
• (b) Modifying Methods.

30
Schema Evolution

• (2) Changes to inheritance hierarchy
• (a) Making a class S superclass of a class C.
• (b) Removing S from list of superclasses of C.
• (c) Modifying order of superclasses of C.
• (3) Changes to set of classes, such as creating
  and deleting classes and modifying class names.
• Changes must not leave schema inconsistent.

31
Schema Consistency

• 1. Resolution of conflicts caused by multiple
  inheritance and redefinition of attributes and
  methods in a subclass.
• 1.1 Rule of precedence of subclasses over
  superclasses.
• 1.2 Rule of precedence between superclasses of a
  different origin.
• 1.3 Rule of precedence between superclasses of
  the same origin.

32
Schema Consistency

• 2. Propagation of modifications to subclasses.
• 2.1 Rule for propagation of modifications.
• 2.2 Rule for propagation of modifications in the
  event of conflicts.
• 2.3 Rule for modification of domains.

33
Schema Consistency

• 3. Aggregation and deletion of inheritance
  relationships between classes and creation and
  removal of classes.
• 3.1 Rule for inserting superclasses.
• 3.2 Rule for removing superclasses.
• 3.3 Rule for inserting a class into a schema.
• 3.4 Rule for removing a class from a schema.

34
Schema Consistency
35
OODBMS Manifesto

• Complex objects must be supported.
• Object identity must be supported.
• Encapsulation must be supported.
• Types or Classes must be supported.
• Types or Classes must be able to inherit from
  their ancestors.
• Dynamic binding must be supported.
• The DML must be computationally complete.

36
OODBMS Manifesto

• The set of data types must be extensible.
• Data persistence must be provided.
• The DBMS must be capable of managing very large
  databases.
• The DBMS must support concurrent users.
• DBMS must be able to recover from
  hardware/software failures.
• DBMS must provide a simple way of querying data.

37
OODBMS Manifesto

• The manifesto proposes the following optional
  features
• Multiple inheritance, type checking and type
  inferencing, distribution across a network,
  design transactions and versions.
• No direct mention of support for security,
  integrity, views or even a declarative query
  language.

38
Advantages of OODBMSs

• Enriched Modeling Capabilities.
• Extensibility.
• Removal of Impedance Mismatch.
• More Expressive Query Language.
• Support for Schema Evolution.
• Support for Long Duration Transactions.
• Applicability to Advanced Database Applications.
• Improved Performance.

39
Disadvantages of OODBMSs

• Lack of Universal Data Model.
• Lack of Experience.
• Lack of Standards.
• Query Optimization compromises Encapsulation.
• Object Level Locking may impact Performance.
• Complexity.
• Lack of Support for Views.
• Lack of Support for Security.

40
ObjectStore OODBMS - Architecture

• Based on multi-client/multi-server architecture,
  with each server responsible for controlling
  access to an object store and for managing
  concurrency control (locking-based), data
  recovery, and the transaction log, among other
  tasks.
• A client can contact ObjectStore server on its
  host or any other ObjectStore server on any other
  host in network.

41
ObjectStore - Architecture

• For each host machine running one or more client
  applications there is an associated cache manager
  process whose primary function is to facilitate
  concurrent access to data by handling callback
  messages from server to client applications.
• Also, each client application has its own client
  cache, which acts as a holding area for data
  mapped (or waiting to be mapped) into physical
  memory.

42
ObjectStore Architecture
43
ObjectStore Server

• Responsible for
• storage and retrieval of persistent data
• handling concurrent access by multiple client
  applications
• database recovery.

44
Client Application

• Objectstore client library is linked into each
  client application, allowing it to
• map persistent objects to virtual addresses
• allocate and deallocate storage for persistent
  objects
• maintain a cache of recently used pages and the
  lock status of those pages
• handle page faults on addresses that refer to
  persistent objects.

45
Client Cache

• Client cache exists to improve access to
  persistent objects.
• When client application needs to access a
  persistent object, then a page fault is generated
  when
• object is not in physical memory and not in
  client cache
• object is in client cache but has not yet been
  accessed
• object is in client cache but has been previously
  accessed with different read/write permissions.

46
Virtual Memory Mapping Architecture (VMMA)

• C object is stored in database in its native
  format with all pointers intact (as opposed to
  swizzling them to OIDs).
• Basic idea of ObjectStore VMMA is same as for
  virtual memory management in operating systems.
• References to objects are realized by virtual
  memory addresses. If an object has to be
  dereferenced and the page object resides on is in
  memory, there is no extra overhead in
  dereferencing this object (dereferencing is as
  fast as for any C/C program).

47
Virtual Memory Mapping Architecture (VMMA)

• If required page is not in memory, a page fault
  occurs and page is brought into same virtual
  memory address it originally occupied.
• Thus, pointers to this object in other
  transferred objects are valid virtual memory
  pointers referring to their original target.
• ObjectStore manages this process by reserving a
  range of unmapped virtual memory for persistent
  objects, thereby ensuring that this range will be
  used for no other purpose than database pages.

48
Data Definition in ObjectStore

• ObjectStore can handle persistence for objects
  created in C/C and Java through separate class
  libraries, and there is facility for objects
  created in one language to be accessed in other.
• For C, ObjectStore uses C as a schema
  language so that everything in database must be
  defined by C class.
• In ObjectStore, persistence is orthogonal to type
  and persistent object support is achieved through
  overloading new operator.

49
Data Definition in ObjectStore

• Also a version of C delete operator to delete
  persistent objects and free persistent memory.
• Once persistent memory has been allocated,
  pointers to this memory can be used in same way
  as pointers to virtual memory. In fact, pointers
  to persistent memory always take form of virtual
  memory pointers.

50
Data Manipulation in ObjectStore

• Following operations must be performed before
  persistent memory can be accessed
• a database must be created or opened
• a transaction must be started
• a database root must be retrieved or created.

51
Roots and Entry Point Objects

• Database root provides way to give an object a
  persistent name, thereby allowing the object to
  serve as an entry point into the database.
• From there, any object related to it can be
  retrieved using navigation (i.e., following data
  member pointers) or by a query (i.e., selecting
  all elements of a given collection that satisfy a
  specified predicate).

52
Roots and Entry Point Objects
53
Access Based on a Named Root

• aBranch (Branch)(db1-gtfind_root(Branch3_Root)
  
• -gtget_value(WorksAtType)
• cout ltlt Retrieval of branch B003 root ltlt
• aBranch-gtbranchNo ltlt \n

54
Iteration of Collections using Cursors

• os_CursorltSalesStaffgt c(aBranch-gtHas)
• cout ltlt Staff associated with branch B003 \n
• for (p c.first() c.more() p c.next())
• cout ltlt p-gtstaffNo ltlt \n

55
Lookup of Single Object Based on Value of one or
more Data Members

• salesStaffExtent (os_SetltSalesStaffgt)
• (db1-gtfind_root(salesStaffExtent_Root)
• -gtget_value(salesStaffExtentType)
• aSalesPerson salesStaffExtent
• -gtquery_pick(SalesStaff,!strcmp(staffNo,\SG3
  7\),
• db1)
• cout ltlt Retrieval of specific member of sales
  staff ltlt aSalesPerson.staffNo ltlt \n

56
Lookup of Single Object Based on Value of one or
more Data Members

• os_SetltSalesStaffgt highlyPaidStaff
• salesStaffExtent-gtquery(SalesStaff,
• salary gt 30000, db1)
• cout ltlt Retrieval of highly paid staff \n
• os_CursorltSalesStaffgt c(highlyPaidStaff)
• for (p c.first() c.more() p c.next())
• cout ltlt p-gtstaffNo ltlt \n