object-oriented databases

65
1 Object-Oriented Databases

Upload: javen

Post on 13-Jan-2016

73 views

Category:

Documents


0 download

DESCRIPTION

Object-Oriented Databases. Outline. Advanced database applications Shortcomings of Relational DBs Object-oriented concepts Object Relational Systems (ORDBMSs) SQL:1999 object extensions Object-oriented database Systems (OODBMSs) ODMG Data Model ODL – data definition language - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Object-Oriented Databases

1

Object-Oriented Databases

Page 2: Object-Oriented Databases

2

Outline• Advanced database applications• Shortcomings of Relational DBs• Object-oriented concepts• Object Relational Systems (ORDBMSs)

– SQL:1999 object extensions

• Object-oriented database Systems (OODBMSs)– ODMG Data Model

– ODL – data definition language

– OQL – query language

Page 3: Object-Oriented Databases

3

Advanced Database Applications

• Computer-Aided Design/Manufacturing (CAD/CAM)• Computer-Aided Software Engineering (CASE)• Network Management Systems• Office Information Systems (OIS) and Multimedia

Systems• Digital Publishing• Geographic Information Systems (GIS)• Interactive and Dynamic Web sites• Other applications with complex and interrelated

objects and procedural data.

Page 4: Object-Oriented Databases

4

Expected features for new applications

• Complex objects

• Behavioral data

• Meta knowledge

• Long duration transactions

Page 5: Object-Oriented Databases

5

Weaknesses of RDBMSs

• Poor representation of “Real World” entities– Normalization leads to relations that do not correspond

to entities in “real world”.

• Semantic overloading– Relational model has only one construct for

representing data and data relationships: the relation.

– Relational model is semantically overloaded

Page 6: Object-Oriented Databases

6

Weaknesses of RDBMSs• Limited operations

– only a fixed set of operations which cannot be extended.

• Difficulty handling recursive queries• Impedance mismatch

– Most DMLs lack computational completeness. – To overcome this, SQL can be embedded in a high-

level language.– This produces an impedance mismatch - mixing

different programming paradigms.– Estimated that as much as 30% of programming effort

and code space is expended on this type of conversion.

Page 7: Object-Oriented Databases

7

Object-Oriented Concepts

• Abstraction, encapsulation, information hiding.• Objects and attributes.• Object identity.• Methods and messages.• Classes, subclasses, superclasses, and inheritance.• Overloading.• Polymorphism and dynamic binding.

Page 8: Object-Oriented Databases

8

Complex Objects

An object that consists of sub-objects but is viewed as a single object.

• Objects participate in a A-PART-OF relationship.• Contained object can be encapsulated within

complex object, accessed by complex object’s methods.

• Or have its own independent existence, and only an OID is stored in complex object.

Page 9: Object-Oriented Databases

9

Database Systems

First Generation DBMS: Network and Hierarchical

– Required complex programs for even simple queries.

– Minimal data independence.

– No widely accepted theoretical foundation.

Second Generation DBMS: Relational DBMS

– Helped overcome these problems.

Third Generation DBMS: OODBMS and ORDBMS.

Page 10: Object-Oriented Databases

10

History of Data Models

Page 11: Object-Oriented Databases

11

Origins of the Object-Oriented Data Model

Page 12: Object-Oriented Databases

12

ORDBMS

Page 13: Object-Oriented Databases

13

ORDBMSs• Vendors of RDBMSs conscious of threat and

promise of OODBMS. • Agree that RDBMSs not currently suited to advanced

database applications, and added functionality is required.

• Reject claim that extended RDBMSs will not provide sufficient functionality or will be too slow to cope adequately with new complexity.

• Can remedy shortcomings of relational model by extending model with OO features.

Page 14: Object-Oriented Databases

14

ORDBMSs - Features

• OO features being added include:– user-extensible types,

– encapsulation,

– inheritance,

– polymorphism,

– dynamic binding of methods,

– complex objects including non-1NF objects,

– object identity.

Page 15: Object-Oriented Databases

15

Stonebraker’s View

Page 16: Object-Oriented Databases

16

Objects in SQL:1999

• Object-relational extension of SQL-92• Includes the legacy relational model• SQL:1999 database = database = a finite set of relations• relationrelation = a set of tuples (extends legacy relations)

OROR

a set of objects (completely new)

• object = object = (oid, tuple-value)• tupletuple = tuple-value

• tuple-valuetuple-value = [Attr1: v1, …, Attrn: vn]

Page 17: Object-Oriented Databases

17

SQL:1999 Tuple Values

• Tuple valueTuple value: [Attr1: v1, …, Attrn: vn]

– AttrAttrii are all distinct attributesare all distinct attributes

– Each Each vi is one of these:is one of these:• Primitive value: a constant of type Primitive value: a constant of type CHAR(…), CHAR(…),

INTEGER, FLOATINTEGER, FLOAT, etc., etc.

• Reference value: an object IdReference value: an object Id

• Another tuple valueAnother tuple value

• A collection valueA collection valueOnly the ARRAYARRAY construct is – a fixed size array.

SETOF and LISTOF are SETOF and LISTOF are not supported.not supported.

Page 18: Object-Oriented Databases

18

Row Types

• The same as the original (legacy) relational tuple type. However:– Row types can now be the types of the individual attributes in

a tuple

CREATE TABLE PERSONPERSON (

Name CHAR(20),

Address ROW(Number INTEGER, Street CHAR(20), ZIP CHAR(5))

)

Page 19: Object-Oriented Databases

19

Row Types (Contd.)

• Use path expressions to refer to the components of row types:SELECT P.NameFROM PERSONPERSON PWHERE P.Address.ZIP = ‘11794’

• Update operations:INSERT INTO PERSONPERSON(Name, Address)VALUES (‘John Doe’, ROW(666, ‘Hollow Rd.’, ‘66666’))

UPDATE PERSONPERSONSET Address.ZIP = ‘66666’WHERE Address.ZIP = ‘55555’

UPDATE PERSONPERSONSET Address = ROW(21, ‘Main St’, ‘12345’)WHERE Address = ROW(123, ‘Maple Dr.’, ‘54321’) AND Name = ‘J. Public’

Page 20: Object-Oriented Databases

20

User Defined Types (UDT)

• UDTs allow specification of complex objects/tuples, methods, and their implementation

• Like ROW types, UDTs can be types of individual attributes in tuples

• UDTs can be much more complex than ROW types (even disregarding the methods): the components of UDTs do not need to be elementary types

Page 21: Object-Oriented Databases

21

A UDT ExampleCREATE TYPE PersonTypePersonType AS (

Name CHAR(20),Address ROW(Number INTEGER, Street CHAR(20), ZIP

CHAR(5)) );

CREATE TYPE StudentTypeStudentType UNDER PersonTypePersonType AS (Id INTEGER,Status CHAR(2)

)METHOD award_degree() RETURNS BOOLEANBOOLEAN;

CREATE METHOD award_degree() FOR StudentTypeStudentTypeLANGUAGE CEXTERNAL NAME ‘file:/home/admin/award_degree’;

File that holds the binary code

Page 22: Object-Oriented Databases

22

Using UDTs in CREATE TABLE

• As an attribute type:

CREATE TABLE TRANSCRIPTTRANSCRIPT (Student StudentTypeStudentType,CrsCode CHAR(6),Semester CHAR(6),Grade CHAR(1)

)

• As a table type:

CREATE TABLE STUDENTSTUDENT OF StudentTypeStudentType;

Such a table is called typed table.typed table.

A previously defined UDT

Page 23: Object-Oriented Databases

23

Objects

• Only typed tables contain objects (ie, tuples with oids)• Compare:

CREATE TABLE STUDENTSTUDENT OF StudentTypeStudentType;

andCREATE TABLE STUDENT1STUDENT1 (

Name CHAR(20), Address ROW(Number INTEGER, Street CHAR(20), ZIP CHAR(5)),

Id INTEGER, Status CHAR(2) )

• Both contain tuples of exactly the same structure• Only the tuples in STUDENTSTUDENT – not STUDENT1STUDENT1 – have oids.• This disparity is motivated by the need to stay backward

compatible with SQL-92.

Page 24: Object-Oriented Databases

24

Querying UDTs

• Nothing special – just use path expressions

SELECT T.Student.Name, T.Grade

FROM TRANSCRIPTTRANSCRIPT T

WHERE T.Student.Address.Street = ‘Main St.’

Note: T.Student has the type StudentTypeStudentType. The attribute Name is not declared explicitly in StudentTypeStudentType, but is inherited from PersonTypePersonType.

Page 25: Object-Oriented Databases

25

Updating User-Defined Types

• Inserting a record into TRANSCRIPTTRANSCRIPT:

INSERT INTO TRANSCRIPTTRANSCRIPT(Student,Course,Semester,Grade)

VALUES (????, ‘CS308’, ‘2000’, ‘A’)

– The type of the Student attribute is StudentTypeStudentType. How does one insert a value of this type (in place of ????)?

– Further complication: the UDT StudentTypeStudentType is encapsulated,encapsulated, ie, it is accessible only through public methods, which we did not define

– Do it through the observerobserver and mutatormutator methods provided by the DBMS automatically

Page 26: Object-Oriented Databases

26

Observer Methods• For each attribute A of type T in a UDT, an SQL:1999 DBMS is supposed to

supply an observer methodobserver method, A: ( ) T, which returns the value of A (the notation “( )” means that the method takes no arguments)

• Observer methods for StudentTypeStudentType:• Id: ( ) INTEGER• Name: ( ) CHAR(20)• Status: ( ) CHAR(2)• Address: ( ) ROW(INTEGER, CHAR(20), CHAR(5))

• For example, inSELECT T.Student.Name, T.GradeFROM TRANSCRIPTTRANSCRIPT TWHERE T.Student.Address.Street = ‘Main St.’

Name and Address are observer methods, since T.Student is of type StudentTypeStudentType

Note: Grade is not an observer, because TRANSCRIPTTRANSCRIPT is not part of a UDT

Page 27: Object-Oriented Databases

27

Mutator Methods

• An SQL:1999 DBMS is supposed to supply, for each attribute A of type T in a UDT U, a mutator methodmutator method

AA:: T T U U

For any object o of type U, it takes a value t of type T and replaces the old value of o.A with t; it returns thenew value of the object. Thus, o.A(t) is an object of type U

• Mutators for StudentTypeStudentType:• Id: INTEGER StudentTypeStudentType• Name: CHAR(20) StudentTypeStudentType• Address: ROW(INTEGER, CHAR(20), CHAR(5)) StudentTypeStudentType

Page 28: Object-Oriented Databases

28

Example: Inserting a UDT ValueINSERT INTO TRANSCRIPTTRANSCRIPT(Student,Course,Semester,Grade)

VALUES (

NEW StudentTypeStudentType( ) .Id(111111111) .Status(‘G5’) .Name(‘Joe Public’)

.Address(ROW(123,’Main St.’, ‘54321’)) ,

‘CS532’,

‘S2002’, ‘A’

)

‘CS532’, ‘S2002’, ‘A’ are primitive values for the attributes Course, Semester, Grade

Create a blank StudentType object

Add a value for Id

Add a value for Status

Add a value for the Address attribute

Page 29: Object-Oriented Databases

29

Example: Changing a UDT Value

UPDATE TRANSCRIPTTRANSCRIPT

SET Student = Student.Address(ROW(21,’Maple St.’,’12345’)).Name(‘John Smith’),

Grade = ‘B’

WHERE Student.Id = 111111111 AND CrsCode = ‘CS532’ AND Semester = ‘S2002’

• Mutators are used to change the values of the attributes Address and Name

Change AddressChange Name

Page 30: Object-Oriented Databases

30

Referencing Objects

• Consider againCREATE TABLE TRANSCRIPTTRANSCRIPT (

Student StudentTypeStudentType,CrsCode CHAR(6),Semester CHAR(6),Grade CHAR(1)

)

• Problem: TRANSCRIPTTRANSCRIPT records for the same student refer to distinct values of type StudentType (even though the contents of these values may be the same) – a maintenance/consistency problem

• Solution: use self-referencing columnself-referencing column– Bad design, which distinguishes objects from their references

– Not truly object-oriented

Page 31: Object-Oriented Databases

31

Self-Referencing Column

• Every typed table has a self-referencing columnself-referencing column– Normally invisible

– Contains explicit object Id for each tuple in the table

– Can be given an explicit name – the only way to enable referencing of objects

CREATE TABLE STUDENT2STUDENT2 OF StudentTypeStudentType

REF IS stud_oid;

Self-referencing columns can be used in queries just like regular columns

Their values cannot be changed, however

Self-referencing column

Page 32: Object-Oriented Databases

32

Reference Types and Self-Referencing Columns

• To reference objects, use self-referencing columns + reference reference typestypes: REF(some-UDT)

CREATE TABLE TRANSCRIPT1TRANSCRIPT1 ( Student REF(StudentTypeStudentType) SCOPE STUDENT2STUDENT2,

CrsCode CHAR(6), Semester CHAR(6), Grade CHAR(1) )

• Two issues:• How does one query the attributes of a reference type• How does one provide values for the attributes of type REF(…)

– Remember: you can’t manufacture these values out of thin air – they are oids!

Reference type

Typed table where the values are drawn from

Page 33: Object-Oriented Databases

33

Querying Reference Types

• Recall: StudentStudent REF(StudentTypeStudentType) SCOPE STUDENT2STUDENT2 in TRANSCRIPT1TRANSCRIPT1.

How does one access, for example, student names?• SQL:1999 has the same misfeature as C/C++ has (and which Java and

OQL do not have): it distinguishes between objects and references to objects. To pass through a boundary of REF(…) use “” instead of “.”

SELECT T.StudentName, T.Grade

FROM TRANSCRIPT1TRANSCRIPT1 TWHERE T.StudentAddress.Street = “Main St.”

Crossing REF(…) boundary, use

Not crossing REF(…) boundary, use “.”

Page 34: Object-Oriented Databases

34

Inserting REF Values• How does one give values to REF attributes, like Student in

TRANSCRIPT1TRANSCRIPT1? • Use explicit self-referencing columns, like stud_oid in STUDENT2STUDENT2

• Example: Creating a TRANSCRIPT1TRANSCRIPT1 record whose Student attribute has an object reference to an object in STUDENT2STUDENT2:

INSERT INTO TRANSCRIPT1TRANSCRIPT1(Student,Course,Semester,Grade)

SELECT S.stud_oid, ‘HIS666’, ‘F1462’, ‘D’

FROM STUDENT2STUDENT2 S

WHERE S.Id = ‘111111111’

Explicit self-referential

column of STUDENT2STUDENT2

Page 35: Object-Oriented Databases

35

Object-Oriented Oracle

An Analysis of the Object-Oriented Features of Oracle’s

Database Management System

Page 36: Object-Oriented Databases

36

Background

• Beginning with Oracle 8 Universal Data Server, Oracle started implementing object-oriented (OO) principals within the database management system.

• Oracle is not a true OO database – object-relational.

• Oracle’s goals for OO support:– Allow users to model business objects via types.– Provide infrastructure to support OO access.

Page 37: Object-Oriented Databases

37

OO Features/Advantages of

Objects in Oracle OO Features: Abstraction Encapsulation Inheritance

Advantages: Object re-use Use of methods Efficiencies Model real-world business objects

Page 38: Object-Oriented Databases

38

Object Type Implementation

Creating Types Similar to creating a “class” with

attributes:

CREATE TYPE addr_ty AS OBJECT

(street varchar2(60),

city var char2(30),

state char(2),

zip varchar(9));

Page 39: Object-Oriented Databases

39

Object Type Implementation

Imbedding Objects and NestingCreate a person type with address type nested

inside:

CREATE TYPE person_ty AS OBJECT

(name varchar2(25),

address addr_ty);

Create a student type with person type nested inside:

CREATE TYPE student_ty AS OBJECT

(student_id varchar2(9),

person person_ty);

Page 40: Object-Oriented Databases

40

Object Type Implementation

Creating an Object TableNow that the student_ty object type has been

defined it can be used in creating an object table like the following:

CREATE TABLE STUDENT

(full_student student_ty);

Page 41: Object-Oriented Databases

41

Object Type ImplementationTo extract data, the following query can be

entered:

SELECT s.full_student.student_id ID, s.full_student.person.name NAME, s.full_student.person.address.street STREET

FROM student s

WHERE s.full_student.student_id = 100

 ID NAME STREET--------- ------------------------- -------------

100 John Q. Student 1000 Chastain Rd.

Page 42: Object-Oriented Databases

42

Object Type Implementation

• Updating and deleting is similar to what one would do in the relational model:

UPDATE STUDENT sSET s.full_student.person.name = 'JOHN NEWNAME'

WHERE s.full_student.student_id = 100; DELETE FROM STUDENT sWHERE s.full_student.student_id = 100;

Page 43: Object-Oriented Databases

43

Implementing Methods

To define a method in a type object:create or replace type newperson_ty as object

(firstname varchar2(25),

lastname varchar2(25),

birthdate date,

member function AGE(BirthDate in DATE) return NUMBER;

Then define the method itself:create or replace type body newperson_ty as

member function AGE(BirthDate in DATE) return NUMBER is

begin

RETURN ROUND(SysDate - BirthDate);

end;

end;

Page 44: Object-Oriented Databases

44

Implementing Methods

To test the method first set up a table holding the person_ty object type:

create table NEWPERSON of newperson_ty;

 

insert into NEWPERSON values

(newperson_ty('JOHN', 'DOE', TO_DATE('03-FEB-1970', 'DD-MON-YYYY')));

 

To call the AGE function we can do the following: select P.PERSON.AGE(P.PERSON.Birthdate)

from NEWPERSON P;

 

P.PERSON.AGE(P.PERSON.Birthdate)

----------------------------------------

12005

Page 45: Object-Oriented Databases

45

Referencing • Every row object has a unique identifier called the

object identifier (OID).• OID allows other objects to reference an existing

row object.• REF function can be used to reference an OID:

create table NEWDEPARTMENT(DeptName VARCHAR(30), PersonIn REF NEWPERSON_TY);

• Table NEWDEPARTMENT holds a reference to a NEWPERSON_TY object, but does not hold any real values.

Page 46: Object-Oriented Databases

46

Referencing

To get a full description of the table just created:

Set describe depth 2Desc NEWDEPARTMENT Name Null? Type --------------- -------- ------------------- DEPTNAME VARCHAR2(30) PERSONIN REF OF NEWPERSON_TY FIRSTNAME VARCHAR2(25) LASTNAME VARCHAR2(25) BIRTHDATE DATE

Page 47: Object-Oriented Databases

47

Referencing• To insert a record into NEWDEPARTMENT, the

REF is needed to store the NEWPERSON reference in the PersonIn column:insert into NEWDEPARTMENTselect 'Research',REF(P)from NEWPERSON Pwhere LastName = 'DOE';

• The literal value “Research” is inserted into the NEWPERSON table.

• The REF function returns the OID from the query on the selected NEWPERSON object.

• The OID is now stored as a pointer to the row object in the NEWPERSON object table.

Page 48: Object-Oriented Databases

48

Referencing• The referenced value cannot be seen unless the DREF

function is used. The DREF function takes the OID and evaluates the reference to return a value.

select DEREF(D.PersonIn)from NEWDEPARTMENT Dwhere DEPTNAME = 'Research'

DEREF(D.PERSONIN)(FIRSTNAME, LASTNAME, BIRTHDATE)----------------------------------------------------NEWPERSON_TY('JOHN', 'DOE', '03-FEB-70')

• This shows that the NEWPERSON record JOHN DOE is referenced by the Research record in NEWDEPARTMENT.

Page 49: Object-Oriented Databases

49

Referencing• To gather the same structure of the object type

of an object table the VALUE function is required.

select value(p)from newperson pwhere lastname = 'DOE' VALUE(P)(FIRSTNAME, LASTNAME, BIRTHDATE)-----------------------------------------NEWPERSON_TY('JOHN', 'DOE', '03-FEB-70')

Page 50: Object-Oriented Databases

50

ReferencingPL/SQL Sample:

set serveroutput ondeclare v_person NEWPERSON_TY;beginselect value(p) into v_personfrom NEWPERSON pwhere lastname = 'DOE';DBMS_OUTPUT.PUT_LINE(v_person.firstname);DBMS_OUTPUT.PUT_LINE(v_person.lastname);DBMS_OUTPUT.PUT_LINE(v_person.birthdate);end;  JOHNDOE03-FEB-70

Page 51: Object-Oriented Databases

51

Inheritance Create a root type of an object hierarchy:

create type PERSON_TY as object(name varchar2(25), birthdate date, member function AGE() return number, member function PRINTME() return varchar2);

To create a subtype the following syntax can be used:

create type EMPLOYEE_TY under PERSON_TY (salary number,member function WAGES() return number,overriding member function PRINTME() return varchar2);

Page 52: Object-Oriented Databases

52

OODBMS

Page 53: Object-Oriented Databases

53

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.

Page 54: Object-Oriented Databases

54

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.

Page 55: Object-Oriented Databases

55

Advantages of OODBMSs

• Enriched Modeling Capabilities. • Removal of Impedance Mismatch.• More Expressive Query Language.• Support for Schema Evolution.• Support for Long Duration Transactions.• Applicability to Advanced Database Applications.

Page 56: Object-Oriented Databases

56

Disadvantages of OODBMSs

• Lack of Universal Data Model.• Lack of Experience.• Lack of Standards.• Query Optimization compromises Encapsulation.• Object Level Locking may impact Performance.• Complexity.

Page 57: Object-Oriented Databases

57

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.

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

Page 58: Object-Oriented Databases

58

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.

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

Page 59: Object-Oriented Databases

59

Two-Level Storage Model for RDBMS

Page 60: Object-Oriented Databases

60

Single-Level Storage Model for OODBMS

Page 61: Object-Oriented Databases

61

Object Data Management Group(ODMG)

• Established by vendors of OODBMSs to define standards.

• The ODMG Standard includes :– Object Data Model (ODM).– Object Definition Language (ODL).– Object Query Language (OQL).– C++, Smalltalk, and Java Language Binding.

Page 62: Object-Oriented Databases

62

The Structure of an ODMG Application

Page 63: Object-Oriented Databases

63

Main Idea: Host Language = Data Language

• Objects in the host language are mapped directly to database objects

• Some objects in the host program are persistentpersistent. Changing such objects (through an assignment to an instance variable or with a method application) directly and transparently affects the corresponding database object

• Accessing an object using its oid causes an “object faultobject fault” similar to pagefaults in operating systems. This transparently brings the object into the memory and the program works with it as if it were a regular object defined, for example, in the host Java program

Page 64: Object-Oriented Databases

64

Architecture of an ODMG DBMS

Page 65: Object-Oriented Databases

65

SQL Databases vs. ODMG

• In SQL: Host program accesses the database by sending SQL queries to it (using JDBC, ODBC, Embedded SQL, etc.)

• In ODMG: Host program works with database objects directly