3C13/D6

III. Current Trends

Part 3: Object-Oriented DBMSs: Concepts and Design
Lecture 12

Lecturer: Chris Clack

III. Current Trends: 3 - Object DBMSs: concepts and design

Slide 1/22

12.0 Content

Content
12.1 Objectives 12.2 Introduction to OO data models and OODBMSs
- Persistent programming languages (PPLs) - Alternative strategies for developing an OODBMS

12.3 OODBMS Perspectives

- Pointer swizzling Techniques

12.4 Persistence
- Persistence schemes - Orthogonal persistence

12.5 Issues in OODBMSs

Transactions Versions Schema Evolution Architecture Benchmarking

12.6 The OO database System Manifesto 12.7 Advantages and disadvantages of OODBMSs
Slide 2/22

III. Current Trends: 3 - Object DBMSs: concepts and design

12.1 Objectives

In this Lecture you will learn:

Objectives

Framework for an OODM. Basics of persistent programming languages (PPLs). Main strategies for developing an OODBMS. Single-level v. two-level storage models. Pointer swizzling. Persistence schemes. Advantages and disadvantages of orthogonal persistence. Issues underlying ODBMSs. Advantages and disadvantages. OODBMS Manifesto.
Slide 3/22

III. Current Trends: 3 - Object DBMSs: concepts and design

12.2 Introduction to OO data models and OODBMSs

No one agreed object data model

Introduction to OO data models and OODBMSs

OODM: Object-Oriented Data Model. Data model that captures

semantics of objects supported in object-oriented programming.

OODB: Object-Oriented Database. Persistent and sharable collection of

objects defined by an ODM.

OODBMS: Object-Oriented DBMS. Manager of an ODB.

Zdonik & Maiers threshold model that OODBMS must, at a min:
provide database functionality. support object identity. provide encapsulation. support objects with complex state.

Khoshafian & Abnous OODBMS definition: OO= ADTs + Inheritance + Object identity OODBMS= OO + Database capabilities.
Slide 4/22

III. Current Trends: 3 - Object DBMSs: concepts and design

12.2 Introduction to OO data models and OODBMSs

Persistent Programming Languages (PPLs)

PPL: 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. - PPLs eliminate impedance mismatch by extending programming language with database capabilities PPL Motivations: Improving programming productivity by using simpler semantics Removing ad hoc arrangements for data translation and storage Providing protection mechanisms over the whole environment

The more encompassing term Persistent App System (PAS) is sometimes used now.
III. Current Trends: 3 - Object DBMSs: concepts and design Slide 5/22

12.2 Introduction to OO data models and OODBMSs

Alternative Strategies for Developing OODBMSs

1.
2.

3.

4.

5.

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. 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.
Slide 6/22

III. Current Trends: 3 - Object DBMSs: concepts and design

12.3 OODBMS Perspectives

OODBMS Perspectives
-Traditional programming languages lack built-in database features support -Increasing no. of apps require functionality from both database and PLs -Apps need to store/retrieve large amounts of shared, structured data. Traditional DBMS difficulties: programmer has to:
-Decide when to read and update objects. -Write code to translate between apps object and DBMS data model -Perform additional type-checking when object is read back from database, to guarantee object will conform to its original type.

Two-level storage model (Conventional DBMSs): storage model in memory, database storage model on disk. Single-level storage model (OODBMSs): illusion of, with similar representation in both memory and in database stored on disk. Requires clever management.
III. Current Trends: 3 - Object DBMSs: concepts and design Slide 7/22

12.3 OODBMS Perspectives

Pointer Swizzling Techniques

Single-Level Storage Model requires clever management of representation of objects in memory and on disk (called pointer swizzling).
Pointer Swizzling: action of converting OIDs to main memory pointers.
-Aim is to optimize access to objects. -Should be able to locate any referenced objects on secondary storage using OIDs.

Techniques 1. No Swizzling: - Easiest implementation is not to do any swizzling. - Objects faulted into memory, and handle passed to app containing OID. - OID is used every time the object is accessed. - System maintains lookup table so objects virtual memory pointer can be located and then used to access object. - Inefficient if same objects are accessed repeatedly.
III. Current Trends: 3 - Object DBMSs: concepts and design Slide 8/22

12.3 OODBMS Perspectives

Pointer Swizzling Techniques

2. 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.

- Node marking requires that all object references are immediately converted to virtual memory pointers when object is faulted into memory.
3. 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. - Avoids overhead of residency checks incurred by software approaches.
III. Current Trends: 3 - Object DBMSs: concepts and design Slide 9/22

12.3 OODBMS Perspectives

Pointer Swizzling Techniques

Three other issues that affect swizzling techniques:
1. Copy versus In-Place Swizzling: When faulting objects in, data can either be copied into apps 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: have to unswizzle entire page of objects if one modified 2. Eager versus Lazy Swizzling: More relaxed definition restricts swizzling to all persistent OIDs within object the app wishes to access. - Eager swizzling: swizzling all OIDs for persistent objects on all data pages used by app, before any object can be accessed. - Lazy swizzling only swizzles pointers as they are accessed
III. Current Trends: 3 - Object DBMSs: concepts and design Slide 10/22

12.3 OODBMS Perspectives

Pointer Swizzling Techniques

3. Direct versus Indirect Swizzling: Only an issue when swizzled pointer can refer to object that is no longer in virtual memory. Direct swizzling: virtual memory pointer of referenced object is placed directly in swizzled pointer. 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.

III. Current Trends: 3 - Object DBMSs: concepts and design

Slide 11/22

12.4 Persistence

DBMS must provide support for persistent objects, ones that survive after creator program has terminated.
1. Checkpointing: Copy all/part programs address space to 2ndary storage. Two main drawbacks:
1. Can only be used by program that created it. 2. May contain large amount of data that is of no use in subsequent executions.

Persistence schemes

2. Serialization: Copy closure of a data structure to disk. Two inherent problems:

1. Does not preserve object identity. 2. Not incremental, saving small changes to a large data structure is not efficient

3. Explicit Paging: Object only made persistent if explicitly declared as such within the application program. By class: class statically declared to be persistent, all instances made persistent when they are created. By explicit call: object specified as persistent when created or at runtime.
III. Current Trends: 3 - Object DBMSs: concepts and design Slide 12/22

12.4 Persistence

Alternative mechanism for providing persistence. 3 fundamental principles:

1. Persistence independence: persistence of object independent of how program manipulates that object. code fragment independent of persistence of data it manipulates. Programmer does not need to control movement of data between longterm and short-term storage. 2. Data type orthogonality: All data objects should be allowed full range of persistence irrespective of their type. No special cases where object is not allowed to be long-lived/transient 3. Transitive persistence: how to identify/provide persistent objects at language level independent of choice of data types in the language. Technique that is now widely used for identification is reachability-based.
III. Current Trends: 3 - Object DBMSs: concepts and design Slide 13/22

Orthogonal Persistence

12.4 Persistence

Orthogonal Persistence
Advantages: Improved programmer productivity from simpler semantics. Improved maintenance. Consistent protection mechanisms over whole environment. Support for incremental evolution. Automatic referential integrity. Disadvantages: Some runtime expense in a system where every pointer reference might be addressing persistent object. System required to test if object must be loaded in from disk-resident database. Although orthogonal persistence promotes transparency, system with support for sharing among concurrent processes cannot be fully transparent.
III. Current Trends: 3 - Object DBMSs: concepts and design Slide 14/22

12.5 Issues in OODBMSs

Issues in OODBMSs
Previously: problem areas for relational databases:
Long duration transactions Versions Schema evolution How these issues are addressed in OODBMSs: 1. Transactions: unit of concurrency control and recovery is an Object. - Locking based protocols most common type of CC mechanism - Multiversion CC protocols & advanced T models, such as sagas 2. Versions: Allow changes to properties of objects to be managed so that object references always point to correct object version. Itasca identifies 3 types of versions:
1. 2. 3. Transient Versions. Working Versions. Released Versions.

III. Current Trends: 3 - Object DBMSs: concepts and design

Slide 15/22

12.5 Issues in OODBMSs

Issues in OODBMSs
3. Schema Evolution: Some apps require considerable flexibility in dynamically defining and modifying database schema Typical schema changes: (1) Changes to class definition: (a) Modifying Attributes. (b) Modifying Methods. (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.

III. Current Trends: 3 - Object DBMSs: concepts and design Slide 16/22

12.5 Issues in OODBMSs

Architecture
Three basic Client-server architectures:
1. Object Server: distribute processing between the two components. Typically, client is responsible for T management & interfacing to PL Server responsible for other DBMS functions. Best for cooperative, object-to-object processing in an open, distributed environment. 2. Page Server: Most database processing is performed by client. Server responsible for secondary storage and providing pages at clients request. 3. Database Server: Most database processing performed by server. Client passes requests to server, receives results and passes to app. Approach taken by many RDBMSs.
III. Current Trends: 3 - Object DBMSs: concepts and design Slide 17/22

12.5 Issues in OODBMSs

Storing and executing methods

Two approaches: (a) Store methods in external files. (b) Store methods in database.

Benefits of (b): Eliminates redundant code. Simplifies modifications. Methods are more secure. Methods can be shared concurrently. Improved integrity.
III. Current Trends: 3 - Object DBMSs: concepts and design Slide 18/22

12.5 Issues in OODBMSs

Benchmarking: 2 Examples
Wisconsin Benchmark: Developed to allow comparison of particular DBMS features. Consists of set of tests as a single user covering:
updates/deletes involving key and non-key attributes projections involving different degrees of duplication in the atts and different selections on indexed/non-index and clustered atts joins with different selectivities aggregate functions.

OO7 (Object Operations Version 7): More comprehensive set of tests and database based on parts hierarchy. Designed for detailed comparisons of OODBMS products. Simulates CAD/CAM environment, tests system performance of object-to-object navigation over cached data, disk-resident data, and sparse/dense traversals. Also tests indexed/nonindexed updates of objects, repeated updates, and the creation and deletion of objects.
III. Current Trends: 3 - Object DBMSs: concepts and design Slide 19/22

12.6 OO manifesto

The OO Database system manifesto

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 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. 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.
Slide 20/22

+ optional features including type checking/inferencing, versions

III. Current Trends: 3 - Object DBMSs: concepts and design

12.7 Advantages/disadvantages of OODBMSs

Advantages/disadvantages of OODBMSs
Advantages: Enriched Modeling Capabilities. Extensibility. Removal of Impedance Mismatch. More Expressive Query Language. Support for Schema Evolution. Support for Long Duration Ts. Applicability to Advanced Database Apps. Improved Performance. Disadvantages: 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.

III. Current Trends: 3 - Object DBMSs: concepts and design

Slide 21/22

12.7 Summary

Summary
12.1 Objectives 12.2 Introduction to OO data models and OODBMSs

Persistent programming languages (PPLs) Alternative strategies for developing an OODBMS

Pointer swizzling Techniques Persistence schemes Orthogonal persistence Transactions Versions Schema Evolution Architecture Benchmarking

12.3 OODBMS Perspectives 12.4 Persistence 12.5 Issues in OODBMSs

NEXT LECTURE:
III Current Trends Part 4: Object-Relational DBMSs: background to ORDBMS third manifesto Postgres-An Early ORDBMS Query Processing and Optimization

12.6 The OO database System Manifesto 12.7 Advantages and disadvantages of OODBMSs
Slide 22/22

III. Current Trends: 3 - Object DBMSs: concepts and design