Object-Oriented Databases Chapter 11

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

6. 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)

7. Different approaches to designing OODB 1. 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 • 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

24. OSQL – Object SQL  • 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 table Create 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 dereference Select DEREF(drives) from registrations; //If you want to display the OIDs of the objects in a table use: Select REF(p) from people p;

34. Examples Notice the difference between a REF and the object_type_name( ) form How to insert tuples and query : Example of object-relational in Oracle Results from above in SQL Example if creating objects with circular dependencies Set (collection of objects) – nested tables or VARRAY

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

36. 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;

37. Methods member function getName return name_t is begin return name_t(fname, minit, lname); end get Dependent;

38. Methods MEMBER FUNCTION getGender return varchar is BEGIN IF self.sex=‘M’ then return ‘Male’; ELSE return ‘Female’; END IF; END;

39. Methods create type employee_t as object ( ssn int, etc. member function getGender return varchar, member function getName return name_t);

40. To invoke methods • Select e.getName(), e.getGender() from employee e;

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?)

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

43. Versions • Version hierarchy - timestamps user: specify versioned object trace version history delete 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

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)