1 / 21

CS457 Object-Oriented Databases Chapters 21-22 as reference

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

josiah
Download Presentation

CS457 Object-Oriented Databases Chapters 21-22 as reference

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

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 ODB 1. 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

More Related