cs457 object-oriented databases chapters 21-22 as reference

Post on 31-Jan-2016

44 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

CS457 Object-Oriented Databases Chapters 21-22 as reference. Limitations to the relational model? Examples of applications that will not work well with the relational model?. Shortcomings of DB models for:. CAD/CAM - keep track of 1000's of matching parts and subassemblies - PowerPoint PPT Presentation

TRANSCRIPT

1

CS457 Object-Oriented Databases

Chapters 21-22 as reference

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• OA (office automation)• multimedia databases• WWW

4

Different because of:

• more complex structures for objects

• new data types for storing images, text, user defined types

• nonstandard application specific operations

• stored procedures (available in some RDBS, such as ORACLE) 

5

OODB systems

• prototypes: ORION, IRIS, ENCORE,

• Commercial products: Postgres, ObjectStore, Versant, Objectivity/DB, O2, Itasca (commercial version of ORION), Gemstone/Opal, POET

6

OODB 

• Some people felt the word object-oriented is too close to OOPL

• ODB is more generic

7

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

OOPL (1st generation OODB)• language, compiler, execution environment, etc.

extended to incorporate – DB functionality – store and manage objects created by OOPL 

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

• Already familiar with DBMS but performance decreased  

• Postgres - extended Ingres, Oracle

9

Designing cont’d

3. Start entire process from scratch (next generation?)

• unify relational and OO system  

10

Object Data Model

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

attributes and operations– Data object has OID - immutable– Group data objects into classes - 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 hierarachy (ISA) – specialization - define new

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

12

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

13

ODM

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

14

ODM

Object identity OID

• correspondence between real-world and database objects

• used to refer to objects in application programs and in references between objects (relationships) 

• unique identity to each independent object

15

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

16

Swizzling

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

• pointer to other memory resident objects - swizzling

• saves OID lookup with subsequent references

17

ODM

Encapsulation• information and operations, structure and behavior• implementation hidden• define behavior of object using operations• object accessible through predefined operations -

methods• method invoked by sending messages• If query on attributes? SQL violates

encapsulation

18

  OSQL – Object SQL 

• ODMG has provided standards for ODB just like relational databases.

• Result is OSQL

19

Implementation Issues:

• composite objects• nested - no joins needed

– path queries instead of joins

• pointer (OID) to nested object• 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 

20

Placing objects on disk?

• clustering of objects– all of same class together– subclass follows superclass

• nested objects

• indexes for objects? (just like relations)

21

Additional topics

• schema evolution?• views?

• Extended relational• Now object-relational

– Examine Oracle documentation to see how OO features included in 9i

– Can create both tables and objects

top related