1

Object-Oriented Databases

Chapter 11

2

 

• Limitations to the relational model?

• Examples of applications that will not work well with the relational model?

3

Shortcomings of DB models for:

• CAD/CAM - keep track of 1000's of matching parts and subassemblies– relational inefficient for this– object versioning

• complex market-oriented operations (securities)

• geographical information systems• CASE• multimedia databases• WWW

4

Different because of:

• requirements and characteristics that differ from traditional business applications

• more complex structures for objects• new data types for storing images, text, user

defined types• nonstandard application specific operations

5

OODB systems

• Prototypes: ORION, IRIS, ENCORE,• Commercial products:

– ObjectStore V7.3 (free download, mentions big data)

– Versant V8 (free downloads)– Objectivity/DB10 (mentions big data), also has

InfiniteGraph– Discontinued: Itasca based on Orion, POET

OODB systems

• Open source object database– PostgreSQL 9.1 (or is it ORDB?)– Perst (McObject) – supports SQL, ACID, etc.

• Used by DirectTV

– Db4o – queries only in Java, C#, VB.NET (owned by Versant)

– Magma 4.2 ?? Still around, old websites – Squeak (smalltalk-Gemstone)

6

7

Different approaches to designing OODB1. Applications written in extension of existing

OOPL (1st generation OODB) to include:• DB functionality

– store and manage objects created by OOPL– DB features such as transactions, concurrency

control, etc.   • Selling point - unified programming and DB language but

need query optimization, etc. – Gemstone (Smalltalk), Poet (C++)

8

Designing cont’d 2. Extend relational DB to include OO features:

– OID, type hierarchy, inheritance, encapsulation, arbitrary data types, nested objects, etc.

– Query language extended with programming capability

– application communicates with DBMS through embedded query language calls in application program

– Already familiar with DBMS but performance decreased  

• Postgres - extended Ingres, Oracle

9

Designing cont’d

3. Start entire process from scratch - unify relational and OO system

– (next generation?)–   NO

10

Object Data Model - ODM

• Bring concepts of OOPL into DB systems– Object corresponds to mini-world object– Object is data and behavior, object has

attributes and operations (methods)• Encapsulation (SQL, optimization?)

– Data object has OID – immutable• Identity vs. value based• Generated by system

– Group data objects into classes (or types) - abstract mechanism, share same structure and behavior

11

ODM

Class has:– instances– methods and data - encapsulation for information

hiding - access only through methods– composite classes - composed of multiple types– nested objects - contains another object– complex objects - set of objects      – class hierarchy (ISA) – specialization - define new

classes from existing ones– inheritance of attributes and methods - reuse

12

ODM

Encapsulation• implementation hidden• define behavior of object using operations• object accessible through predefined operations• If query on attributes?

– SQL violates encapsulation • SQL for visible (OSQL), rest is encapsulated

13

ODM

Completeness• DBS needs to be computationally

complete (Turing)• SQL not computationally complete -

unless embedded SQL – impedance mismatch, since sets

• connections with DML and OOPL in ODB more acceptable

14

ODM

Add features such as: – concurrency – recovery – schema evolution– Versions– What about query language?– Performance?

15

ODM

Object identity OID• correspondence between real-world and

database objects• OIDs like RIDs except can point to other OIDs• used to refer  to objects in application programs

and in references between objects(relationships) • unique over entire DB and even over distributed

DB

16

OID vs. primary key

• identity based vs. value-based• unique over entire DB and even over distributed DB (if

primary key changes, still same real-world object)• immutable - values of OID for object should not change

- OID not assigned to another object

- not dependent on any attribute values

- not use physical address      • system generated OID• not visible to user

17

OIDs in reality

• in extended ODMSs, query language extended to allow access by OID

• in OOPL, allow value based access by key

• in Postgres - oid attribute in every tuple

18

OID Implementation

1.  physical address - fast – rarely  used, cannot move or delete - if so, all

references must be changes also

2.  structured addresses - popular, 1-2 disk accesses

physical and logical component    segment and page # and logical slot number         if change, use forwarding 

19

OID Implementation cont’d

•    3.  surrogates - poorer retrieval – purely logical – use any algorithm to produce unique IDs

(e.g. date, time) – use hash index to map to physical address

(Postgres) – object pages are hash buckets - single disk

access

20

OID Implementation cont’d

• 4.  typed surrogate - like surrogate for retrieval – contains type ID and object ID – can obtain type without fetching it - ORION – difficult to change type - may be useful to be

able to segment address space (distributed)

21

OID Implementation

• More efficient for artificially generated identifiers

• Performance improved if generate OID to speed object lookup

22

Swizzling

• All references in cached objects replaced with object's address

• pointer to other memory resident objects - swizzling

• saves OID lookup with subsequent references

23

Implementation Issues:

• pointer (OID) to nested object• nested - no joins needed

– path queries instead of joins

• when bring in an object into memory, bring in nested objects as well

• replace OID with memory address (can't do this in relational)– eager and lazy swizzling

• fast access - memory resident 

OSQL – Object SQL 

24

• ODMG (disbanded) provided standards for ODB just like relational databases.

• Result is OSQL (object SQL)

25

Object-relational - ORDMS

• Informix, IBM, Hewlett-Packard, Unisys, Oracle, and UniSQL

• “Extended relational" is probably the more appropriate term

• ORDMSs specified by the extensions to the SQL standard, SQL3/4

• http://en.wikipedia.org/wiki/Comparison_of_object-relational_database_management_systems

26

ORDMS

• Superset of RDMS• Definition?

– Allows user defined types– User defined functions– Indexing/access methods to support them

• ORDBMSs have had their greatest success in managing media objects and complex data such as geospatial and financial time series data

• frequently used in Web applications and specialized data warehouses

27

Oracle’s object relational

• Oracle ORDB– Relaxes 1NF– Has object types, so users can create tables

and objects– Allows users to create

• Types as objects• Object tables

– OIDs– Inheritance

28

Create type• Create type must be followed by a / in SQL Plus (; optional)• No objects created, like a struct type// Create object type

Create type name_t as object ( lname varchar(10),

fname varchar(10), mi char(1) ) /

// Create relational tableCreate table teachers

( tid int, tname name_t, room int) /

29

How to insert?

Can use object_type_name( ) form as an object constructor,

Builds objects from value of attributes

Insert into teachers values (1234, name_t(‘Sky’, ‘Sue’, ‘V’), 120);

NOTE: data in name_t is never an OID, it is just the data or a copy of the data if stored elsewhere

30

Path queries

Select t.tname.lname from teachers t where room = 120;

// sometimes aliases are required

// in my examples always use them

31

Create Object table

Create type person_t as object(ssn int,Pname name_t,age int)/

Create table people of person_t;

To query people:// You can use the usual SQL

Select * from people where age > 25;

//Or you can use: value ( )Select value(p) from people p where age > 25;

32

Inheritance

CREATE TYPE vehicle AS OBJECT

(VID VARCHAR2(20),

COLOR CHAR(10),

MAKE VARCHAR2(10),

MODEL VARCHAR2(10) ) NOT FINAL

/ CREATE TYPE car UNDER vehicle

( DOORS NUMBER,

SPORT CHAR(1) )

/

33

Ref Object reference//Use REF keyword to point to a row object

Create type car_reg as object ( license int, drives ref car)

Create table registrations of car_reg;

//Use dot notation to follow a REF to derefence a REF:Select r.drives.vid from registrations r;

// or can use DEREF to dereferenceSelect DEREF(drives) from registrations;

//If you want to display the OIDs of the objects in a table use:Select REF(p) from people p;

         

Examples

Notice the difference between a REF and the object_type_name( ) form

How to insert tuples and query :

Example of object-relational in OracleResults from above in SQLExample if creating objects with circular

dependenciesSet (collection of objects) – nested tables or

VARRAY

34

Nested tables

create type dependent_t under person_t(

essn ref employee_t,

relationship varchar(10))

create type dependent_tbl as table of dependent_t

35

Nested tables

Create type employee_t under person_t(

ssn int,

address varchar(30),

…

dependent dependent_tbl;

• You also need:

Create table employee of employee_t nested table dependent store as dependent_table;

36

Methods

member function getName return name_t is

begin

return name_t(fname, minit, lname);

end get Dependent;

37

Methods

MEMBER FUNCTION getGender return varchar is

BEGIN

IF self.sex=‘M’ then

return ‘Male’;

ELSE

return ‘Female’;

END IF;

END;

38

Methods

create type employee_t as object (ssn int, etc.

member function getGender return varchar,

member function getName return name_t);

39

To invoke methods

• Select e.getName(), e.getGender() from employee e;

40

41

Performance

• Performance of OODB affected by: – cache sizes– clustering (all of same class together versus

subclass follows superclass)– Nested objects– Indexes (just like relations)– views – swizzling – Replication– Versions (replicate common data?)

Versions

• Shared version (not updatable)– Check out and update– Deleted only by owner

• Working version– Update/delete by owner– New transient derived from existing one– Existing promoted to working

42

Versions

• Version hierarchy - timestampsuser: specify versioned objecttrace version historydelete version (delete all versions created from it

or just most recent)merge

• Class if versionable– Generic object– Default version#– Next version#– Version description– Working or transient

43

44

OODB issues

• physical OODB design – clustering problems (NP-hard) – placing objects onto pages so number of

page faults is minimal

• user hints for clustering • where to stores objects, near related

objects • how to store objects, near related objects

45

Example

• e.g.  Bob is a person, but also an employee   store all persons   Bob Sally Joe Bill           Bob Bill        Sally Joe        person                       employee       students   if store extra attributes, must also retrieve information from person class

• store as       employee   student retrieve all of them for person

46

Schema evolution

• Schema evolution – dynamically define and modify DB schema – invariant - set of properties of the schema – rules for preserving invariance

• 2 types of schema changes: – 1.  definition of a class (contents

(attribute/method) of node) – 2.  to structure (edges and nodes)