Object Oriented Databases

Object Oriented Databases 1. Advanced Database Applications 2. Object-Oriented Concepts 3. OODBMS 4. Common Issues 4. ODMG 2.0 Ioan Despi

1. Advanced Database Applications RDBMS: widespread acceptance for traditional business applications: order processing, inventory control, banking, airline reservations proven inadequate for new technologies: computer-aided design (CAD), computer-aided manufacturing (CAM), computer-aides software engineering (CASE), office information systems and multimedia systems, digital publishing, geographic information systems

Disadvantages of Relational DBMS: Poor representation of “real world” entities. Semantic overloading Poor support dor integrity and enterprise constraints. Homogenous data structure. Limited operations. Difficulty handling recursive queries Impedance mismatch. Other problems concerning: concurrency, schema access, navigational access, and so on

2. Object- Oriented Concepts Loosely speaking, an object correspond to an entity in the ER model. The object -oriented paradigm is based on encapsulating data and code related to an object into a single unit. Abstraction: the process of identifying the essential aspects of an entity and ignoring the unimportant properties. 1. Encapsulation: an object contains both the data structure and the set of operations that can be used to manipulate it. 2. Information hiding: we separate the external aspects of an object from its internal details, which are hidden from the outside world. The internal details of an object can be changed without affecting the application that use it.

The current state of an object is described by one or more attributes, or instance variable. The value of each variable is itself an object. 1. A simple attribute: can be a primitive type (integer, string, real,… 2. A complex-attribute: can contain collections and/or references 3. A reference attribute: represents a relationship between objects contains a value or collection of values, which are themselves objects (like a Foreign Key or a pointer) Complex object: an object that contains one or more complex attributes Notation: “dot” notation: branch.street, branch.manager, branch.city Object= a uniquely identifiable entity that contains both the attributes that describe the state of the object and the actions that are associated with it, that is its behaviour.(Simula)

The behaviour of an object is given by: a set of messages to which the object responds each message may have 0, 1 or more parameters a set of methods, each of which is a body of code to implement a message a method returns a value as the response to the message The physical representation of data is visible only to the implementor of the object. Messages and responses provide the only extenal interface to an object. The term message does not necessarily imply physical message passing. Messages can be implemented as procedures calls.

Object showing attributes and methods Method 1 Method 4 Attributes Method 2 Method 3

Methods are programs written in a general-purpose language respecting thee following restrictions: 1. Only variables in the object itself may be referenced directly 2. Data in other objects are referenced only by sending messages They can be used to change the object’s state by modifying its attribute values, or to query the values of selected attributes. A method consists of a name and a body that performs the behavior associated with the method name: method void update_salary (float increment) { salary = salary + increment; }

Messages are the means by which objects communicate. A message is simply a request from an object (the sender) to another object (the receiver)asking the second object to execute one of its methods. The sender and receiver may be the same object. The “dot” notation is generally used to access a method. staff_object.update_salary(1000) In a traditional programming language, a message would be written as a function call: update_salary(staff_object, 1000)

Object classes Similar objects (have the same attributes, respond to the same messages) are grouped into a class. The attributes and associated methods are defined once for the class. Al objects in a class have the same: variable types message interface methods They may differ in the values assigned to variables Classes are analogous to entity sets in the ER model. Example: all branch objects would be described by a single Branch class.

BRANCH bno=B5 street=12 Deer St city=Sidcup area=London ... Attributes bno street city area … bno=B7 street=16 Dever St city=Dyce area=Aberden ... Methods print update_tel_no …. bno=B3 street=154 Main St city=Partick area=Glasgow ...

A class is an object ===>has is own class attributes and class methods The class is an instance of a higher-level class called metaclass Class attributes describes the general characteristics of the class, such as totals or averages( ex: total no of branches) Class methods are used to change or query the state of class attributes There are special class methods to create new instances of the class: new --constructor destructor In the following example, employment-length is a derived attribute. For strict encapsulation, methods to read and set other variables are also needed

classemployee { /*Variables */ string name; string address; date start-date; int salary; /* Messages */ int annual-salary; string get-name; string get-address; int set-address ( string new-address) int employment-length; };

Inheritance Inheritance allows one class (subclass) to be defined as a special case of a more general class (superclass). The process of forming a superclass is referred to as generalization. The process of forming a subclass is referred to as specialization. By default, a subclass inherits all the properties of its superclass(es) and, additionally, defines its own unique properties. A subclass can redefine inherited methods. All instances of the subclass are also instances of the superclass. Principle of substitutability: we can use an instance of the subclass whenever a method or a construct expects an instance of the superclass..

The relation between the subclass and superclass: A KIND OF (AKO) The relation between an instance and its class: IS-A. Examples: Manager is AKO Staff. Susan Deer IS-A Manager. Inheritance: 1. Single inheritance: the subclass inherits from no more than one superclass 2. Multiple inheritance: the subclass inherits from more than one superclass ===> conflicts!

Person Single inheritance Staff Manager Sales_Staff Multiple inheritance Sales_Staff Manager Sales_Manager

3. Repeated inheritance: a special case of multiple inheritance superclasses inherit from a common superclass The inheritance mechanism must ensure that the subclass does not inherits properties twice. Staff Manager Sales_Staff Sales_Manager 4. Selective inheritance:allows a subclass to inherit a limited number of properties from the superclass.

Object Identity Each object is assigned an Object Identifier (OID) when it is created that is: system generated unique to that object invariant independent of the values of its attributes inivisible to the user Other concepts: overriding (+ overloading) polymorphism & dynamic binding complex objects persistence

3. OODBMS Hierarchical Data Model IMS 1960 - 1970 First generation DBMS Network Data Model E. Codd, 1970 1970 - 1980 Relational Data Model Second generation DBMS Chen, 1976 ER Data Model Third generation DBMS Semantic Data Model 1980-2000 Hammer, McLeod, 1981 Object-Relational Data Model Object Oriented Data Model

OODM: a logical data model that captures the semantics of objects supported in oo programming OODB : a persistent and sharable collection of objects defined by an OODM OODBMS: the manager of an OODB (W. Kim 1991) Zdonik &Maier(1991) ---An OODBMS must (at minimum) satisfy: must provide database functionality must support object identifier must provide encapsulation must support objects with complex state or (Khoshafian &Abnous 1990) object oriented= ADT + Inheritance + OID OODBMS= OO + database capabilities

Traditional DBMS • persistence • sharing • transasctions • concurrency control • recovery control • security • integrity • quering • OO programming • object identity • encapsulation • inheritance • types & classes • methods • complex objects • polymorphism • extensibility Object Oriented Data Model • Special requirements • versionong • schema evolution • Semantic data models • generalization • aggregation

Strategies for Developing an OODBMS: 1. Extend an existing object-oriented programming language with database capabilities. Smalltalk, C++, Java --> GemStone 2. Provide extensible object-oriented DBMS libraries. Ontos, Versant, ObjectStore 3. Embed object-oriented database language constructs in a convenient host language. O2embeds OODL in C. 4. Extend an existing database language with object-oriented capabilities. Extend SQL--> SQL3, OQL. 5. Develop a novel database data model / data language. SIM (semantic information manager, 1988).

OODBMS Perspectives: Modern database systems are characterized by their support of the following features: 1. Data model: a particular way of describing data, relationships between data, and constraints on the data 2. Data persistence: the ability of data to outlive the ecxecution of a program, and possibly thee lifetime of the program itself. 3. Data sharing: the ability of multiple applications to access common data, possibly at the same time 4. Reliability: the assurance that the data in the database is protected from hardware and software failures 5. Security : the protection of the data against unauthorized access

7. Integrity: the assurance that the data conforms to specified correctness and consistency rules 8. Distribution: the ability to physically distribute a logically interrelated collection of shared data over a network Traditional programming languages provide: 1. Constructs for procedural control and for data and functional abstraction 2. Lack built-in support for many of the above database features Novel applications require functionality from both perspectives.

Issues: 1. Persistence: objects must survive user session or application program that created them has terminated transient objects: only last for the invocation of the program To implement persistence in OODB: 3 schemes • A. Checkpointing: copy all or part of a program’s address space to secondary storage • a checkpoint can only be used by the program that created it • a checkpoint may contain a large amount of data that is of no use in subsequent executions

B. Serialization: copy the closure of a data structure to disk. • A write operation on a data value involves the traversal of the graph of objects reachable from the value and, then, the writing of a flattened version of the structure to disk. • Reading back this flattened structure: serialization, pickling, marshaling. • Does not preserve object identity: if two data structures that share a common sunstructure are separately serialized, then on retrieval the substructure will no longer be shared in the new copies. • It is not incremental, and so saving small changes to a large data structure is not efficient.

C. Explicit paging: paging objects between the application heap and the persistent store. Requires the conversion of object pointers from a disk-based scheme to a memory-based scheme. There are two common methods for creating/updating persistent objects: a. Reachability-based: an object will persist if it is reachable from a persistent root object at any time after creation, an object can become persistent by adding it to the reachability tree. Garbage collection: deletes objects when they are no longer accessible from any other object Smalltalk, Java

b. Allocation-based: an object is explicitely declared as being persistent within the application program i) By class:  a class is statically declared to be persistent --> all instances of the class are made persistent when they are created  a clas may be a subclass of a system- supplied persistent class Ontos, Objectivity/DB ii) By explicit call: an object may be specified as persistent when it is created or, in soome cases, dynamically at runtime (added to a persistent collection) ObjectStore

Alternatively, to provide persistence in a programming language: orthogonal persistence, based on the following principles: 1. Persistence independence: the persistence of a data object is independent of how the program manipulates the data object and conversely, a fragment of the program is expressed independently of the persistence of data it manipulates. 2. Data type orthogonality: all data objects should be allowed the full range of persistence irrespective of their type: Ps-algol, Napier88, Galileo, GemStone Persistence is only a quality attributable to a subset of the language data types: Pascal/R, Amber, E, Avalon/C++ 3. Transitive persistence: the choice of how to identify and provide persistent objects at the language level is independent of the choice of data types in the language. Most used technique: reachability-based.

Orthogonal persistence: Advantages: 1. There is no need to define long-term data in a separate schema language 2. No special application code is required to access or update persistent data 3. There is no limit to the complexity of the data structures that can be made persistent 4. Improved programmer productivity from simpler semantics 5. Improved maintenance 6. Consistent protection mechanisms over the whole environment 7. Support for incremental evolution 8. Automatic referential integrity

Issues: 2. Pointer Swizzling Techniques: the action of converting object identifiers (OIDs) to main memory pointers, and back again Aim: to optimize access to objects. Obvious approach: to hold a lookup table that maps OIDs to main memory pointers Pointer swizzling: stores the main memory pointers in the place of the referenced OIDs and vice versa, when the object has to be written back to disk

A. No swizzling: the OID is used every time the object is accessed the system maintains a lookup table, so that the object’s virtual memory pointer can be located and then used to access the object. Could be inefficient if the same objects are accessed repeatedly Could be acceptable if applications access an object once B. Object referencing: to be able to swizzle a persistent object’s OID to a virtual memory pointer, a mechanism is required to distinguish between resident and non-resident objects. Most techniques are variations of edge marking or node marking: (Hoskings&Moss, 1993):

Virtual memory is considered to be a directed graph, with objects as nodes and references as directed edges: 1. Edge marking marks every object pointer with a tag bit. If the bit is set, then the reference is to a virtual memory pointer Otherwise, it is still pointing to an OID and needs to be swizzled when the object it referes to is faulted into the application’s memory space. 2. Node marking requires that all object references are immediately converted to virtual pointers when the object is faulted into memory. 1 is a software-based technique; 2 can be implemented using software or hardware-based techniques.

C. Hardware-based schemes: use virtual memory access protection violations to detect accesses of non-resident objects(Lamb91) Use the standard virtual memory hardware to trigger the transfer of persistent data from disk to main memory. Once a page has been faulted in, objects are accessed on that page via normal virtual memory pointers. The hardware approach avoids the overhead of residency checks incurred by software approaches but limits the amount of data that can be accessed during a transaction to the size of virtual memory and complicates other issues, like recovery, fine-grained locking, aso. ObjectStore, Texas

Issues: 3. Transactions in classical DBMSs: short duration transactions in CAD, CASE,…: long duration transactions (hours, days) a need for new protocols: nested transactions, sagas, multi-level transactions. 4. Versions: Ontos, Versant, ObjectStore, Objectivity/DB, Itasca object version = an identifiable state of an object version history = the evolution of an object version management = object references always point to the correct version of an object

Types of versions: 1. Transient version: unstable, can be updated and deleted it can be created from new by checking out a released version from a public database or by deriving it from a working or transient version in a private database, when the base transient version is promoted to a working version. Always sored in the creator’s private workspace. 2. Working version: stable and cannot be updated but it can be deleted by its creator. It is stored in the creator’s private workspace. 3. Released version: stable, cannot be updated or deleted. it is stored in a public database by checking in a working version from a private database

Issues: 5. Schema evolution: design is an incremental process. To support this process, applications require flexibility in dynamically defining and modifying the database schema. Typical changes to the schema include: changes to the class definition: modifying attributes, modifying methods changes to the inheritance hierarchy: making a class S the superclass of a class C, removing a class S from the list of superclasses of C, modifying the order of superclasses of C changes to the set of classes: creating and deleting classes, modifying class names

Client - Server Architectures: 1. Object server: distributes the processing between the two components Server process: responsible for managing storage, locks, commits to secondary storage, logging, recovery, security, query optimization and executing stored procedures Client process: responsible for transaction management and interfacing to the programming languages 2. Page server: most of the database processing is performed by the client. Server process: responsible for secondary storage and for providing pages at the client’s request

3. Database server: most of the database processing is performed by the server. Client process: passes requests to the server, receives results and passes them on to the application. Used by relational DBMS In each case, the server resides on the same machine as the physical database. The client may reside on the same or different machine. If the client needs access to databases distributed across multiple machines, then the clients communicates with a server on each machine. There may be a number of clients communicating with one server: for example, one client for each user or application.

Advantages od OODBMSs: enriched modeling capabilities extensibility removal of impedance mismatch more expressive query language support for schema evolution support for long duration transactions aplicability to advanced database applications improved performance

Disadvantages of OODBMSs: lack of universal data model lack of experience lack of standards query optimization compromises encapsulation locking at object level may impact performance complexity lack of support for views lack of support for security

Object Database Standard ODMG 2.0 1997 Object Database Management Group proposed an OODM consisting of: 1. An object model 2. An object definition language (ODL) (like traditional DDL) 3. An object query language, with a SQL-like syntax ODMG object model is a superset of the Object Management Group (OMG) object model. 1990: OMG published its Object Management Architecture (OMA) Guide document . It specified a single terminology for oo languages, systems, databases and applications.

Application objects Common facilities WP Spreadsheet CAD Help email browser Object Request Broker Transaction management queries versioning security storage Object services OMA

1. The Object Model-- OM is a design-portable abstract model for communicating with OMG-compliant object-oriented systems a requester sends a request for object services to the ORB which keeps track of all the objects in the system and the types of services they can provide the ORB then forwards the message to a provider who acts on the message and passes a response back to the requester via the ORB requester ORB provider

2. The Object Request Broker -- ORB handles distribution of messages between application objects is a distributed ‘software bus’ that enables objects (requesters) to make and receive requests and responses from a provider on receipt of a response from the provider, the ORB translates the response into a form the original requester can understand --> provides a mechanism by which objects make and receive requests and responses transparently --> interoperability between applications in a heterogeneous distributed environment

3. The Object Services --OS provide the main functions for realizing basic object functionality collection: a uniform way to create and manipulate most common collections generically: sets, queues, stacks, lists, binary trees concurrency control: a lock manager that enables multiple clients to coordinate their access to shared rresources event management: allows components to dynamically register or unregister their interest in specific events exeternalization: provides protocols and conventions for externalizing and internalizing objects.

externalization: records the state of an object as a stream of data (in memory, on disk, across network) internalization: creates a new object from it in a different process licensing: operations for metering the use of components to ensure fair compensation for their use, and protect intellectual property lifecycle: operations for creating, copying, moving, and deleting groups of related objects naming: facilities to bind a name to an object relative to a naming context persistence: interfaces to mechanisms for storing and managing objects persistently property: operations to associate named values (properties) with any (external) component

query: declarative query statements with predicates, the ability to invoke operations and other object services relationship: a way to create dynamic associations between components that know nothing of each other security: services such as identification and authentification, authorization and access control, auditing, security of communication, non-repudiation, administration time: maintains a single notion of time across different machines trader: a matchmaking service for objects. It allows objects to dynamicaly advertise their services, and other objects to register for a service. transactions: a two-phase commit coordination among recoverable components using flat or nested transactions

4. The Common Facilities --CF comprise a set of tasks that many applications must perform but are traditionally duplicated within each one. they are made available through OMA-compliant class interfaces in the latest version: CF are split in horizontal common facilities (printing, electronic mail, aso) and vertical domain facilities (finance, helthcare, manufacturing, e-commerce, transportation, telecommunications)

The Common Request Broker Architecture -- CORBA defines the architecture of ORB-based environments is the basis of any OMG component, defing the parts that form the ORB and its associated structure 1991: CORBA 1.1 defined: Interface Definiton Language (IDL) Application Programming Interfaces (API) - enable client- server interaction with a specific implementation of an ORB 1994dec: CORBA 2.0 improved interoperability specified how ORBs from different vendors can interoperate 1997: CORBA 2.1

Object Oriented Databases