Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Object-relational databases
  2. 2. Outline <ul><li>What is an ORDBMS ? </li></ul><ul><li>Need for ORDBMSs </li></ul><ul><li>Characteristics of an ORDBMS </li></ul><ul><li>SQL3 – ‘object-oriented’ SQL </li></ul><ul><li>State of the art: Oracle 8 and IBM DB2 UDB </li></ul><ul><li>References </li></ul>
  3. 3. What is an ORDBMS ? <ul><li>A combination of: </li></ul><ul><li>(1) OO features </li></ul><ul><ul><li>Complex objects </li></ul></ul><ul><ul><li>Functions </li></ul></ul><ul><ul><li>Inheritance and overloading </li></ul></ul><ul><ul><li>AND </li></ul></ul><ul><li>(2) RDBMS features </li></ul><ul><ul><li>Tables, views </li></ul></ul><ul><ul><li>Transactions, recovery, indexing, optimization </li></ul></ul><ul><ul><li>SQL queries </li></ul></ul>
  4. 4. A brief look at the object-relational model <ul><li>Add ‘object oriented-ness’ to tables </li></ul><ul><li>Data is still stored in tables </li></ul><ul><li>Support for abstract data types, complex objects & user defined functions allows complex relationships and data to be stored and queried </li></ul><ul><li>SQL3 (‘object-oriented’ SQL) is the language for data definition, manipulation, and query. </li></ul>
  5. 5. Need for the O-R approach Simple Data Complex Data No Query Query
  6. 6. Need for the O-R approach.. <ul><ul><li>New data types are appearing (e.g., multimedia) </li></ul></ul><ul><ul><li>Real-world data doesn't fit neatly into tables </li></ul></ul><ul><ul><ul><li>Entities and relationships (vs. tables) </li></ul></ul></ul><ul><ul><ul><li>Variance among entities (vs. homogeneity) </li></ul></ul></ul><ul><ul><ul><li>Set-valued attributes (vs. normalization) </li></ul></ul></ul><ul><ul><li>Advanced applications bring complex data </li></ul></ul><ul><ul><ul><li>E.g., CAD/CAM data management, web data management, geographic information management, medical data management </li></ul></ul></ul><ul><ul><ul><li>So maybe objects are the answer...? </li></ul></ul></ul><ul><ul><li>Yes, if we can keep all the relational &quot;goodies&quot;! </li></ul></ul>
  7. 7. Characteristics of object-relational databases <ul><li>SQL support for Base Data Type Extension </li></ul><ul><li>SQL support for Complex Objects </li></ul><ul><li>SQL support for Inheritance </li></ul><ul><li>Support for a production Rule System </li></ul>
  8. 8. Base Data Type Extension <ul><li>1. Creating a new base data type: </li></ul><ul><ul><li>Create type my_type ( </li></ul></ul><ul><ul><li>internallength = 8, </li></ul></ul><ul><ul><li> input = mytypeInput, </li></ul></ul><ul><ul><li> output = mytypeOutput); </li></ul></ul><ul><ul><li>Create table my_table (name varchar(20) , some_data my_type ); </li></ul></ul>
  9. 9. Base Data Type Extension.. <ul><li>2. Creating a user defined function: </li></ul><ul><li>create function hourly_pay (int) returns float as select ($1/2000); </li></ul><ul><li>Function usage: </li></ul><ul><li>Select name from emp where hourly_pay (salary) >12.50; </li></ul><ul><li>Functions can also be defined in C, Java and used in SQL queries. </li></ul>
  10. 10. Additional requirements <ul><li>Dynamic linking of user-defined functions </li></ul><ul><li>Client or Server Activation of user-defined functions </li></ul><ul><li>Secure User-Defined Functions </li></ul><ul><li>Arbitrary-length data types </li></ul>
  11. 11. Complex objects <ul><li>Type constructors: </li></ul><ul><ul><li>Composites (records) </li></ul></ul><ul><ul><li>Sets </li></ul></ul><ul><ul><li>References </li></ul></ul>
  12. 12. Composites <ul><ul><li>create type phone_t ( area varchar(3), number varchar(3), description varchar(20)); </li></ul></ul><ul><ul><li>create type dept_t (dname varchar(30), floor </li></ul></ul><ul><ul><li>int, phone phone_t, manager varchar(30), manager_ref ref(employee_t)); </li></ul></ul><ul><ul><li>Usage: </li></ul></ul><ul><ul><li>create table dept of type dept_t; </li></ul></ul>
  13. 13. SQL extensions needed for composite types <ul><li>1. User-defined functions take arguments or return a result of a composite type. </li></ul><ul><li>e.g.: select sum_digits( phone ) from dept where dname = ‘HR’; </li></ul><ul><li>2. Functions returning a composite type can appear in the from clause of an SQL query. </li></ul><ul><li>3. The ‘cascaded dot notation’ references attributes of a composite object. </li></ul><ul><li>e.g.: select phone.number from dept where dname = ‘HR’; </li></ul><ul><li>These extensions are also required for sets of composites. </li></ul>
  14. 14. References <ul><li>References are a substitute for the primary key-foreign key concept. </li></ul><ul><li>The manager_ref column is a reference (pointer) to a record of type employee_t. </li></ul><ul><li>SQL extensions needed: </li></ul><ul><ul><li>A deref function that returns the composite </li></ul></ul><ul><ul><li>Allow functions to take arguments or return results of type reference. </li></ul></ul>
  15. 15. Inheritance <ul><li>Inheritance only applies to types. </li></ul><ul><li>Data inheritance example: </li></ul><ul><li>create type person_t(name varchar(20)); </li></ul><ul><li>create type student_t (gpa float, address varchar(10)) under person_t; </li></ul><ul><li>create type employee_t(salary int, department varchar(20), address varchar(60)) under person_t; </li></ul><ul><li>create type student_employee_t(percent float) under employee_t,student_t; </li></ul>
  16. 16. Inheritance hierarchy person_t employee_t student_t student_emp_t
  17. 17. <ul><li>Ambiguity: ‘Address’ appears in both student_t and employee_t types. </li></ul><ul><li>Alternatives: </li></ul><ul><ul><li>Redefine the address field in one of super types </li></ul></ul><ul><ul><li>Database administrator resolves the ambiguity. </li></ul></ul>
  18. 18. Table hierarchy person emp student student_emp Select name from emp where salary = 10000; will examine ‘emp’ and ‘student_emp’ tables. To examine ONLY the ‘emp’ table: Select name from only(emp) where salary = 10000;
  19. 19. Function inheritance Overpaid Query: Select e.name from emp e where overpaid(e); is evaluated on the emp and student_emp tables. The student_emp_t type inherits the overpaid function from employee_t. person_t employee_t student_t student_emp_t Overpaid Overpaid
  20. 20. Production Rule system <ul><li>1. Update update rule (triggers) </li></ul><ul><li>2. Query update rule </li></ul><ul><li>3. Update query rule </li></ul><ul><li>4. Query query rule </li></ul><ul><li>Drawbacks: </li></ul><ul><li>Multiple rules fired by 1 event </li></ul><ul><li>Chain rules cause infinite loops </li></ul><ul><li>Aborting action part of a rule terminates whole transaction </li></ul>
  21. 21. The SQL3 standard <ul><li>An ANSI, ISO standard </li></ul><ul><li>Object-oriented features added to SQL2 </li></ul><ul><li>The foundation for ORDBMS products such as Oracle8 and DB2 UDB </li></ul><ul><li>New data types </li></ul><ul><ul><li>LOB (large object) </li></ul></ul><ul><ul><li>Composite types: ROW and ARRAY </li></ul></ul><ul><li>New predicates: </li></ul><ul><ul><li>SIMILAR </li></ul></ul><ul><ul><li>DISTINCT </li></ul></ul>
  22. 22. SQL3 <ul><li>Object oriented extensions to SQL3: </li></ul><ul><ul><li>Support for structured user-defined types </li></ul></ul><ul><ul><li>Support for user-defined functions </li></ul></ul><ul><ul><li>Support for triggers </li></ul></ul><ul><ul><li>Support for references </li></ul></ul>
  23. 23. IBM DB2 UDB <ul><li>OSF (Object Strike Force) group at IBM Almaden </li></ul><ul><ul><li>Focus: O-R extensions in DB2 Universal Database version 5.2 </li></ul></ul><ul><li>V5.2 of UDB contains new O-R features </li></ul><ul><ul><li>Structured types with inheritance </li></ul></ul><ul><ul><li>Object tables and table hierarchies </li></ul></ul><ul><ul><li>References and path expressions </li></ul></ul><ul><ul><li>Object views and view hierarchies </li></ul></ul>
  24. 24. New O-R features in DB2 UDB 5.2 <ul><li>Structured types and references </li></ul><ul><ul><li>Named types with attributes, O-O subtyping model </li></ul></ul><ul><ul><li>Ref (T) for directly modelling relationships </li></ul></ul><ul><li>Typed tables and table hierarchies </li></ul><ul><ul><li>Oid (user-provided) plus a column per attribute of T </li></ul></ul><ul><ul><li>Subtables for querying and managing subtype instances </li></ul></ul><ul><li>Query language extensions </li></ul><ul><ul><li>Substitutability for queries/updates (data independence ++) </li></ul></ul><ul><ul><li>Path expressions for querying relationships easily </li></ul></ul><ul><ul><li>Functions/predicates for runtime type inquiries </li></ul></ul><ul><li>Object views (via a novel approach) </li></ul><ul><ul><li>Virtual table hierarchies for flexible access control </li></ul></ul><ul><ul><li>Also facilitates O-O views of legacy tables </li></ul></ul>
  25. 25. Object views in DB2 UDB vdept vperson vemp vstudent dept mgr create type VPerson_t as ( name Varchar(40)) ; create type VEmp_t under VPerson_t as (dept Ref (VDept_t)); create type VStudent_t under VPerson_t as (kind Varchar(8)); create type VDept_t as ( name Varchar(20), mgr Ref (VEmp_t));
  26. 26. Typed view hierarchies <ul><li>Now create typed views (and subviews) </li></ul><ul><li>create view vperson of VPerson_t ( ref is oid user generated ) as </li></ul><ul><li>select VPerson_t(Varchar(oid)), name from only (person); </li></ul><ul><li>create view vemp of VEmp_t under vperson </li></ul><ul><li>(dept with options scope vdept) as </li></ul><ul><li>select VEmp_t(Varchar(oid)), name, VDept_t(Varchar(dept)) </li></ul><ul><li>from emp where salary > 0; </li></ul><ul><li>create view vstudent of VStudent_t under vperson as </li></ul><ul><li>select VStudent_t(Varchar(oid)), name, </li></ul><ul><li>case when major like '%Engineer%' then 'Geek' </li></ul><ul><li>else 'non-Geek' end from student; </li></ul><ul><li>create view vdept of VDept_t ...; </li></ul>
  27. 27. Oracle 8 <ul><li>Claimed as “object-enabled” RDBMS. </li></ul><ul><li>Oracle takes an evolutionary approach to object-orientation. In general, Oracle supports OO with a special layer on top of the relational database. </li></ul>
  28. 28. O-O features <ul><li>1. User-Defined datatype (UDT) </li></ul><ul><li>2. User-Defined function (UDF) </li></ul><ul><li>3. Object View and Object Cache, Object Type Translator </li></ul>
  29. 29. Summary <ul><li>Applications that have complex data and queries should use ORDBMSs. </li></ul><ul><li>Major vendors (Oracle, DB2, Illustra) have ORDBMS products </li></ul><ul><li>A better and standardized solution to the multiple inheritance problem is needed. </li></ul><ul><li>Commercial ORDBMS products should conform to SQL3, not just support variants of it – interoperability issues. </li></ul>
  30. 30. References <ul><li>1. Object-Relational DBMSs The Next Great Wave – </li></ul><ul><li>Michael Stonebraker </li></ul><ul><li>2. SQL:1999, formerly known as SQL3 </li></ul><ul><li>Andrew Eisenberg, Jim Melton </li></ul><ul><li>3. O-O, What are they doing to Relational databases? </li></ul><ul><li>Michael J. Carey IBM Almaden January 1999 </li></ul><ul><li>4. Modeling Object Relational Databases, DBMS April </li></ul><ul><li>1998 </li></ul><ul><li>5. Object Database vs. Object-Relational Databases </li></ul><ul><li>Steve McClure IDC Bulletin #14821E - August 1997 </li></ul>
  31. 31. Questions ?