Object oriented DataBase Prof. Sin-Min Lee Department of Computer Science

Object Database Systems Not a new concept – research dates back to the mid-1970s As the technology matured, a number of commercial ODBMSs appeared in the 80s and early 90s To compete with RDBMSs, it became clear that a standard for ODBMSs, analogous to SQL, was needed

Object-Oriented and Multimedia Databases The object-oriented database (OODB) contains both the text data of traditional databases plus information about the set of actions that can be taken on the data fields. Many OODBs are multimedia databases that include graphics, audio information and animation.

Object Orientation Modeling and development methodology A set of design and development principles based on objects Objects – self-contained, reusable modules that contain data as well as their procedures

OOP – Object oriented Programming OO concepts in Ada, Algol, LISP, SIMULA OOPLs – Smalltalk, C++, Java Provide for – –SW development environment –SW modeling tool –Reduce the amount of code –Reusable code

Objects Data and procedures bound together form an Object Data is no longer passive The object can act on itself (recursive)

OOP Terminology Object Identity (OID) Attributes (Instance variables) Object State Messages and Methods Encapsulated Structure –The ability to hide the object ’ s internal details

OOP Terminology Object Class –the logical structure of an object (name, attributes, methods) Object Class Library –a group of object classes Object –an instance of an object class Protocol – –collection of messages

OOP Terminology Superclasses Subclasses Inheritance –Single –Multiple

OOP Terminology Polymorphism –situation in which one name can be used to invoke different functions Inheritance –automatically assuming the attributes and methods of another object at a higher class

Object Classification Simple object Composite object Compound object Hybrid object Associative object

OOP Example

PERSON NAME S ADDRESS S DOB S SEX S AGE I Instance variables John Smith 123 Easy St 23-Nov-1970 M 32 Object Instances

Instance Variables ADTs NAME FIRST_NAME S MIDDLE_NAME S LAST_NAME S ADDRESS STREET_NUM S STREET S APARTMENT S CITY S STATE S ZIP I DOB DAY I MONTH I YEAR I

PERSON EmployeeStudent SuperClass Subclasses

Representing 1:M Relationships (Premiere Products Example) Customer SS# Name Address Balance Cred_Lim Sales_Rep 1 Name Address Tot_Comm Com_Rate Customer M

Representing M:M Relationships Manufacturer Code Name Address Contact: Person 1 Item Code Description Quantity Unit_Price Manufacturers: Manufacturer M Items: Item M

Late Binding ‘A desirable characteristic of OO development is its ability to let any object’s attribute contain object that define different data types (or classes) at different times. ‘

Late binding AttributesRDBMS Item_TypeNumeric DescriptionChar VendorNumeric WeightNumeric PriceNumeric Instance variablesOODB Item_TypeInv_Type DescriptionString_of_charVendorWeight PriceMoney

OODBMS Object-Oriented Features Conventional DBMS OO Concepts OO data models OOPL GUI Data accessibility Persistence Backup and Recovery Transaction Processing Concurrency Security/Integrity Administration

13 Rules for an OODBMS from the OODBS Manifesto System must support complex objects Object identifier must be supported Objects must be encapsulated Systems must support types or classes System must support inheritance System must avoid premature binding System must be computationally complete System must be extensible

Object Database Systems The vendors formed a consortium, the Object Database Management Group (ODMG), to define a standard Current standards specification is ODMG 2.0 Architecture has four major components – a data model, a specification language, a query language, and language bindings

Object Data Model Based upon the (Object Management Group) OMG Object Model OMG is another consortium of vendors instituted to create standards Besides an object model, they oversee standards for UML and CORBA (Common Object Request Broker Architecture)

Object Model Two basic modeling primitives – objects and literals An object has a unique identifier A literal has no identifier Every object and every literal is categorized by its type – a set of values and a set of supported operations

Object Model An object’s state is characterized by a set of properties An object property can be either an attribute or a relationship to another object The set of operations that can be executed on or by an object defines the behavior of an object

Object Model An operation may have input and/or output parameters, and may return a value The type of each parameter and the returned value must be specified A database stores objects, which can be shared by multiple users and applications A database is based on a schema, defined in the object definition language (ODL)

Types There are two facets to the definition of a type – an external specification and one or more implementations The specification of a type corresponds to what is visible to a user – operations that can be applied to instances, its properties, or state variables, and any exceptions that can be raised by the operations

Types An implementation of a type defines the internal aspects of the objects of a type – how the operations access or modify the properties of an object A class definition and an interface definition may specify both the abstract behavior and the abstract state of an object

Types A literal definition specifies only the abstract state of a literal type An implementation of an object type consists of a representation and a set of methods The representation is a data structure realizing the abstract state of an object or literal, expressed in a language binding

Types Each property is represented by an instance variable The operations of an object type are implemented as procedures expressed in a language binding The internal details of an implementation are invisible to the user

Inheritance Inheritance is a second important characteristic of object orientation The data model supports two constructs supporting inheritance – interfaces and classes Interfaces permit the definition of subtypes A subtype represents the specialization of a more general type (the supertype)

Inheritance The generalization/specialization relationship is often called an “is-a” relationship Interfaces are abstract types – they cannot be instantiated The data model supports multiple inheritance of interfaces

Inheritance Classes support a second form of inheritance, described as the “extends” relationship A class can extend the behavior and state of another class Classes can be instantiated An object is an instance of a class

Inheritance Classes support only single inheritance An interface can inherit from another interface, but not from a class A class can inherit from multiple interfaces and can extend a single class Objects have a number of characteristics – identifiers, names, lifetimes, and structures

Identifiers Unlike the relational model, objects within a database are assigned unique identifiers An identifier is generated by the database system when the object is created They are immutable – although the properties of a object may change, its identifier remains the same throughout its lifetime

Names Object identifiers are commonly used for one object to refer to another An object may also have a name Applications typically refer to some objects by a user-defined name The database internally maps names to identifiers

Lifetimes The lifetime of an object is specified when it is created The are two possible lifetimes – persistent and transient A transient object is allocated memory by an application’s runtime system A transient object’s lifetime is the lifetime of the procedure or process that creates it

Lifetimes Persistent objects are allocated memory and secondary storage that is managed by the ODBMS runtime system A persistent object exists after the process that created it terminates Persistent objects also called database objects Object types and lifetimes are independent

Collection Objects The data model supports a number of container types to store collections of objects All elements of a collection must be of the same type Set object – an unordered collection with no duplicates

Collection Objects Bag object – an unordered collection that may contain duplicate objects List object – an ordered collection of elements Array object – another kind of ordered collection of objects Both lists and arrays are position-oriented

Collection Objects The insertion and removal operations take argument specifying the position at which the element is to be inserted or deleted Both collections are zero-based Removing an element from a list changes the positions of elements in the list tail Removing an element from an array simply replaces the element with a null value

Modeling an Object’s State Two kinds of properties – attributes and relationships An attribute is defined to be of a single type Its type may be either a literal or a class Relationships define associations between two types The data model supports only binary relationships

Modeling an Object’s State Relationships are defined implicitly by specifying traversal paths Traversal paths are always declared in pairs This permits bidirectional traversal from either object in the association The ODBMS is responsible for maintaining the referential integrity of a relationship

Modeling an Object’s State The connectivity of a relationship may be one-to-one, one-to-many, or many-to-many The connectivity is always clear from the syntax of the declaration of a relationship To represent arbitrary n-ary relationships, a designer would create a new class type, each instance of which would represent an n-tuple

Object Definition Language The Object Definition Language (ODL) is used to define the specification of object types Roughly corresponds to the DDL of SQL A designer uses ODL to define a database schema

Structured Types struct Address { stringstreet; stringcity; stringstate; stringzip; };

Interfaces interface Person { attribute string name; attribute Address personAddress; relationship Person spouse inverse Person::spouse; relationship set children inverse Person::parents; relationship list parents inverse Person::children; boolean marrriage(in Person newSpouse); void move(in Address newAddress); };

Classes class Salary { attribute float base; attribute float overtime; }; class Employee : Person (extentemployees) {attribute short empID; attribute Salary annual_salary; void raise(in float new_base); void fire(); };

Classes class Professor extends Employee (extentprofessors) { attribute enum Rank {full, associate, assistant} rank; relationship set teaches inverse Section::is_taught_by; };

LAST 5 RULES System must be able to remember data locations System must be able to handle very large databases System must support concurrent users System must be able to recover from hardware and software Data query must be simple

OODBMS ObjectStore ………….. Object Design, Inc. Objectivity/D ………… Objectivity Inc. Versant OODBMS …. Versant Corp ONOS*Integrator ….ONTOS, Inc FastObjects …………….. Poet Software

Why not use a Traditional Relational DBMS? The traditional Relational DBMS stores data in tables, rows, and columns Objects have several complex structures that cannot be represented in tables, rows, or columns. –These structures include executable statements (i.e., methods) and pointers

How are the Relational Database (RDBMS) Manufacturers Responding? The manufacturers of RDBMS are incorporating additional features to allow for the storage of more complex items. Oracle has been particularly active in incorporating these features. –The term object-relational DBMS has been coined to describe this classification of DBMS.

Still developing Lack of standards Is there a sufficient theoretical foundation?

What’s Wrong With ODBMSs? Relationships among objects use object identifiers and must be explicitly designed Critics of the object model refer to the use of object identifiers to implement relationships as “pointer spaghetti” Reminiscent of the older CODASYL network model Difficult to perform ad hoc queries

What’s Wrong With ODBMSs? Vendors don’t support the ODMG standard Only one vendor currently supports OQL There is no capability to create views Robustness, scalability, and fault-tolerance do not measure up to RDBMSs Still an immature field – these problems should be corrected in the future