Chapter 26

1. Chapter 26 Object-Oriented DBMSs – Concepts and Design Transparencies © Pearson Education Limited 1995, 2005

2. Chapter 26 - Objectives • Framework for an OODM. • Basics of the FDM. • Basics of persistent programming languages. • Main points of OODBMS Manifesto. • Main strategies for developing an OODBMS. • Single-level v. two-level storage models. • Pointer swizzling. • How an OODBMS accesses records. • Persistent schemes. © Pearson Education Limited 1995, 2005

3. Chapter 26 - Objectives • Advantages and disadvantages of orthogonal persistence. • Issues underlying OODBMSs. • Advantages and disadvantages of OODBMSs. © Pearson Education Limited 1995, 2005

4. Object-Oriented Data Model No one agreed object data model. One definition: Object-Oriented Data Model (OODM) • Data model that captures semantics of objects supported in object-oriented programming. Object-Oriented Database (OODB) • Persistent and sharable collection of objects defined by an ODM. Object-Oriented DBMS (OODBMS) • Manager of an ODB. © Pearson Education Limited 1995, 2005

5. Object-Oriented Data Model • Zdonik and Maier present a threshold model that an OODBMS must, at a minimum, satisfy: • It must provide database functionality. • It must support object identity. • It must provide encapsulation. • It must support objects with complex state. © Pearson Education Limited 1995, 2005

6. Object-Oriented Data Model • Khoshafian and Abnous define OODBMS as: • OO = ADTs + Inheritance + Object identity • OODBMS = OO + Database capabilities. • Parsaye et al. gives: • High-level query language with query optimization. • Support for persistence, atomic transactions: concurrency and recovery control. • Support for complex object storage, indexes, and access methods. • OODBMS = OO system + (1), (2), and (3). © Pearson Education Limited 1995, 2005

7. Commercial OODBMSs • GemStone from Gemstone Systems Inc., • Objectivity/DB from Objectivity Inc., • ObjectStore from Progress Software Corp., • Ontos from Ontos Inc., • FastObjects from Poet Software Corp., • Jasmine from Computer Associates/Fujitsu, • Versant from Versant Corp. © Pearson Education Limited 1995, 2005

8. Origins of the Object-Oriented Data Model © Pearson Education Limited 1995, 2005

9. Functional Data Model (FDM) • Interesting because it shares certain ideas with object approach including object identity, inheritance, overloading, and navigational access. • In FDM, any data retrieval task can viewed as process of evaluating and returning result of a function with zero, one, or more arguments. • Resulting data model is conceptually simple but very expressive. • In the FDM, the main modeling primitives are entities and functional relationships. © Pearson Education Limited 1995, 2005

10. FDM - Entities • Decomposed into (abstract) entity types and printable entity types. • Entity types correspond to classes of ‘real world’ objects and declared as functions with 0 arguments that return type ENTITY. • For example: Staff() → ENTITY PropertyForRent() → ENTITY. © Pearson Education Limited 1995, 2005

11. FDM – Printable Entity Types and Attributes • Printable entity types are analogous to base types in a programming language. • Include: INTEGER, CHARACTER, STRING, REAL, and DATE. • An attribute is a functional relationship, taking the entity type as an argument and returning a printable entity type. • For example: staffNo(Staff) → STRING sex(Staff) → CHAR salary(Staff) → REAL © Pearson Education Limited 1995, 2005

12. FDM – Composite Attributes Name() → ENTITY Name(Staff) → NAME fName(Name) → STRING lName(Name) → STRING © Pearson Education Limited 1995, 2005

13. FDM – Relationships • Functions with arguments also model relationships between entity types. • Thus, FDM makes no distinction between attributes and relationships. • Each relationship may have an inverse relationship defined. • For example: Manages(Staff) —» PropertyForRent ManagedBy(PropertyForRent) → Staff INVERSE OF Manages © Pearson Education Limited 1995, 2005

14. FDM – Relationships • Can also model *:* relationships: • Views(Client) —» PropertyForRent • ViewedBy(PropertyForRent) —» Client INVERSE OF Views • and attributes on relationships: • viewDate(Client, PropertyForRent) → DATE © Pearson Education Limited 1995, 2005

15. FDM – Inheritance and Path Expressions • Inheritance supported through entity types. • Principle of substitutabilityalso supported. Staff()→ ENTITY Supervisor()→ ENTITY IS-A-STAFF(Supervisor) → Staff • Derived functions can be defined from composition of multiple functions (note overloading): fName(Staff) → fName(Name(Staff)) fName(Supervisor) → fName(IS-A-STAFF(Supervisor)) • Composition is a path expression (cf. dot notation): Supervisor.IS-A-STAFF.Name.fname © Pearson Education Limited 1995, 2005

16. FDM – Declaration of FDM Schema © Pearson Education Limited 1995, 2005

17. FDM – Diagrammatic Representation of Schema © Pearson Education Limited 1995, 2005

18. FDM – Functional Query Languages • Path expressions also used within a functional query. • For example: RETRIEVE lName(Name(ViewedBy(Manages(Staff)))) WHERE staffNo(Staff) = ‘SG14’ • or in dot notation: RETRIEVE Staff.Manages.ViewedBy.Name.lName WHERE Staff.staffNo = ‘SG14’ © Pearson Education Limited 1995, 2005

19. FDM – Advantages • Support for some object-oriented concepts. • Support for referential integrity. • Irreducibility. • Easy extensibility. • Suitability for schema integration. • Declarative query language. © Pearson Education Limited 1995, 2005

20. 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. © Pearson Education Limited 1995, 2005

21. Persistent Programming Languages (PPLs) • PPLs eliminate impedance mismatch by extending programming language with database capabilities. • In PPL, language’s 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. © Pearson Education Limited 1995, 2005

22. 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. © Pearson Education Limited 1995, 2005

23. 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. © Pearson Education Limited 1995, 2005

24. 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. © Pearson Education Limited 1995, 2005

25. 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. © Pearson Education Limited 1995, 2005

26. 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. © Pearson Education Limited 1995, 2005

27. 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. © Pearson Education Limited 1995, 2005

28. 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. © Pearson Education Limited 1995, 2005

29. 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 application’s 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. © Pearson Education Limited 1995, 2005

30. 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”). © Pearson Education Limited 1995, 2005

31. Two-Level Storage Model for RDBMS © Pearson Education Limited 1995, 2005

32. Single-Level Storage Model for OODBMS © Pearson Education Limited 1995, 2005

33. 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. © Pearson Education Limited 1995, 2005

34. Pointer Swizzling Techniques • Could hold lookup table that maps OIDs to memory pointers (e.g. using hashing). • 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. © Pearson Education Limited 1995, 2005

35. No Swizzling • Easiest implementation is not to do any swizzling. • Objects faulted into memory, and handle passed to application containing object’s OID. • OID is used every time the object is accessed. • System must maintain some type of lookup table - Resident Object Table (ROT) - so that object’s 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. © Pearson Education Limited 1995, 2005

36. Resident Object Table (ROT) © Pearson Education Limited 1995, 2005

37. 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. © Pearson Education Limited 1995, 2005

38. 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. © Pearson Education Limited 1995, 2005

39. 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. © Pearson Education Limited 1995, 2005

40. Pointer Swizzling - Other Issues • Three other issues that affect swizzling techniques: • Copy versus In-Place Swizzling. • Eager versus Lazy Swizzling. • Direct versus Indirect Swizzling. © Pearson Education Limited 1995, 2005

41. Copy versus In-Place Swizzling • When faulting objects in, data can either be copied into application’s local object cache or accessed in-place within object manager’s 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. © Pearson Education Limited 1995, 2005

42. 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. © Pearson Education Limited 1995, 2005

43. 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. © Pearson Education Limited 1995, 2005

44. Accessing an Object with a RDBMS © Pearson Education Limited 1995, 2005

45. Accessing an Object with an OODBMS © Pearson Education Limited 1995, 2005

46. Persistent Schemes • Consider three persistent schemes: • Checkpointing. • Serialization. • Explicit Paging. • Note, persistence can also be applied to (object) code and to the program execution state. © Pearson Education Limited 1995, 2005

47. Checkpointing • Copy all or part of program’s address space to secondary storage. • If complete address space saved, program can restart from checkpoint. • In other cases, only program’s heap saved. • Two main drawbacks: • Can only be used by program that created it. • May contain large amount of data that is of no use in subsequent executions. © Pearson Education Limited 1995, 2005

48. Serialization • Copy closure of a data structure to disk. • Write on a data value may involve traversal of graph of objects reachable from the value, and writing of flattened version of structure to disk. • Reading back flattened data structure produces new copy of original data structure. • Sometimes called serialization, pickling, or in a distributed computing context, marshaling. © Pearson Education Limited 1995, 2005

49. Serialization • Two inherent problems: • Does not preserve object identity. • Not incremental, so saving small changes to a large data structure is not efficient. © Pearson Education Limited 1995, 2005

50. Explicit Paging • Explicitly ‘page’ objects between application heap and persistent store. • Usually requires conversion of object pointers from disk-based scheme to memory-based scheme. • Two common methods for creating/updating persistent objects: • Reachability-based. • Allocation-based. © Pearson Education Limited 1995, 2005