1. 1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2006 Object-Relational Database Programming These slides are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. For more information on how you may use them, please see http://www.openlineconsult.com/db

2. 2 © Ellis Cohen 2001-2006 Topics Object-Relational Databases (ORDB's) Joins & Navigation Cell Objects Nested Tables

3. 3 © Ellis Cohen 2001-2006 Object-Relational Databases (ORDB's)

4. 4 © Ellis Cohen 2001-2006 ORDBs Object-Relational Databases integrate an Object Model with the Relational Model. Users can extend the built-in data types (number, date, etc.) with arbitrary object types. Columns can hold references to objects. SQL is extended to support field access and navigation just as in OQL. Tables (containing objects or references to object) are the primary (or sometimes only) collection type. Moreover, objects are not stored independently as in OODBs; they must be placed in tables.

5. 5 © Ellis Cohen 2001-2006 Rows as Objects/Entities empno: 7654 name : MARTIN sal : 1250 comm : 1400 an Employee Object It can be useful to think of each row as an object or entity (i.e. an instance of an entity class) and the table as a collection of these objects The columns of the table correspond to the instance variables for each object It can be useful to think of each row as an object or entity (i.e. an instance of an entity class) and the table as a collection of these objects The columns of the table correspond to the instance variables for each object empno name sal comm Emps 7499ALLEN1600300 7654MARTIN12501400 7698BLAKE2850 7839KING5000 7844TURNER15000 7986STERN1500

6. 6 © Ellis Cohen 2001-2006 Object Tables Object-Relational Databases actually allow rows to be objects (known as row objects), and allow cells to contain references to these row objects. –Referential Integrity constraints can be replaced by actual references –Joins can be replaced by Navigation –Instead of automatically associating an extent with an object, an object is explicitly stored in some table (multiple tables can hold the same type of object) –Every row object has an OID (invisibly provided by the database)

7. 7 © Ellis Cohen 2001-2006 Object Types & Tables CREATE TYPE DeptObj AS OBJECT ( deptno number(3), dname varchar2(20), loc varchar2(15), MEMBER PROCEDURE setLoc( nloc varchar2 ), -- the body of the procedure is defined inside of a TYPE BODY … ) CREATE TABLE DeptTable OF DeptObj (deptno PRIMARY KEY); DeptTable can be viewed as either a table containing 3 columns: deptno, dname, loc a table containing a single column: a DeptObj

8. 8 © Ellis Cohen 2001-2006 Tables of Objects INSERT INTO DeptTable SELECT * FROM dept; SELECT * FROM DeptTable; -- same as SELECT * FROM dept; SELECT VALUE(d) AS objs FROM DeptTable d OBJS(DEPTNO, DNAME, LOC) -------------------------------------------------- DEPTOBJ(10, 'ACCOUNTING', 'NEW YORK') DEPTOBJ(20, 'RESEARCH', 'DALLAS') DEPTOBJ(30, 'SALES', 'CHICAGO') DEPTOBJ(40, 'OPERATIONS', 'BOSTON')

9. 9 © Ellis Cohen 2001-2006 Tables vs Extents Object types do not have a single associated extent There can be multiple tables which hold objects of the same type CREATE TABLE DeptTable1 OF DeptObj (deptno PRIMARY KEY); CREATE TABLE DeptTable2 OF DeptObj (deptno PRIMARY KEY); CREATE TABLE DeptTable3 OF DeptObj (deptno PRIMARY KEY); The user chooses where to store an object INSERT INTO DeptTable2 VALUES ( 50, 'SUPPORT', 'HOUSTON' ); Less signficant issue for DB's which support partitioned tables

10. 10 © Ellis Cohen 2001-2006 Scoped References CREATE TYPE EmpObj AS OBJECT ( empno number(4), name varchar2(30), … dept REF DeptObj SCOPE DeptTable ) CREATE TABLE EmpTable OF EmpObj (PRIMARY KEY empno) REF(obj) creates a reference to the specified object, which can then be returned in a result set UPDATE EmpTable SET dept = (SELECT REF(d) FROM DeptTable d WHERE d.dname = 'ACCOUNTING') WHERE name = 'SMITH' This attribute holds a reference to a DeptObj in DeptTable Change SMITH's dept to ACCOUNTING

11. 11 © Ellis Cohen 2001-2006 Type Inheritance & Checking CREATE TYPE EmpObj UNDER PersonObj ( empno number(4), … dept REF DeptObj SCOPE DeptTable ) CREATE TABLE PersonTable OF PersonObj -- Return empno's of employees in PersonTable SELECT TREAT(p AS EmpObj).empno FROM PersonTable p WHERE p IS OF TYPE EmpObj PersonTable can include EmpObj's as well as other PersonObj's

12. 12 © Ellis Cohen 2001-2006 Joins & Navigation

13. 13 © Ellis Cohen 2001-2006 Comparing Queries In a vanilla RDB, to find the department number in which JONES works, you might do SELECT deptno FROM Emps NATURAL JOIN Depts WHERE ename = 'JONES' In an ORDB using EmpObj (which contains a REF DeptObj) how would you get the deptno in which JONES works? Is the ORDB query or the RDB query faster?

14. 14 © Ellis Cohen 2001-2006 Navigation instead of Joins SELECT dept.deptno FROM EmpTable e WHERE ename = 'JONES'

15. 15 © Ellis Cohen 2001-2006 Unscoped References CREATE TYPE EmpObj AS OBJECT ( empno number(4), name varchar2(30), … dept REF DeptObj SCOPE DeptTable ) CREATE TYPE EmpObj AS OBJECT ( empno number(4), name varchar2(30), … dept REF DeptObj ) This DeptObj could be located in any table. Must use a full-size OID to represent the reference This DeptObj must be located in DeptTable. Can use a table-relative mini-OID to represent the reference

16. 16 © Ellis Cohen 2001-2006 ORDBs Use Direct Navigation CREATE TYPE EmpObj AS OBJECT ( empno number(4), name varchar2(30), …, dept REF DeptObj ) CREATE TABLE EmpTable OF EmpObj (PRIMARY KEY empno) SELECT ename, dept.dname FROM EmpTable e WHERE empno = 6291 Finds the name of employee 6291's dept, whatever table it is stored in

17. 17 © Ellis Cohen 2001-2006 Implementing References w OIDs 622AuditingCHICAGO… deptno dname loc … 6291SMITH…AAAGDxAABA AAH9EAAD27 EmpTable

18. 18 © Ellis Cohen 2001-2006 DELETE & Dangling References DELETE deletes objects from tables of objects Scoped References: provide referential integrity checking: –Can't delete referenced department (default) –ON DELETE SET NULL –ON DELETE CASCADE Unscoped References: no referential integrity checking –If a DeptObj is deleted, a REF DeptObj may hold an invalid OID (a dangling reference) –Use IS DANGLING to check: SELECT DISTINCT e.dept.dname FROM EmpTable e WHERE e.job = 'SALESMAN' AND e.dept IS NOT DANGLING

19. 19 © Ellis Cohen 2001-2006 Multi-Table Queries SELECT dept.deptno FROM EmpTable e WHERE empno = 6291 Suppose in a vanilla RDB, depts were spread across Depts1, Depts2 & Depts3. How would you get the name of the department in which 6291 works? Which one is faster?

20. 20 © Ellis Cohen 2001-2006 Unions for Multi-Table Navigation Suppose in a vanilla RDB, depts were spread across Depts1, Depts2 & Depts3. How would you get the name of the department in which 6291 works? SELECT dname FROM Emps NATURAL JOIN Depts1 WHERE empno = 6291 UNION SELECT dname FROM Emps NATURAL JOIN Depts2 WHERE empno = 6291 UNION SELECT dname FROM Emps NATURAL JOIN Depts3 WHERE empno = 6291;

21. 21 © Ellis Cohen 2001-2006 Cell Objects

22. 22 © Ellis Cohen 2001-2006 Containment ORDB's are non-1NF: Cells may contain objects as well as primitive types of values. These are also called cell objects or column objects. CREATE TYPE Address AS OBJECT( street varchar(100), city varchar(40), state char(2), zip char(5)) CREATE TYPE PersonObj AS OBJECT( name varchar(30), addr Address ) CREATE TABLE PersonTable OF PersonObj

23. 23 © Ellis Cohen 2001-2006 Cell Objects SMITH JONES GOMEZ SONI nameaddr ……MA02139 ……IL51320 ……CA93710 ……MA02445 pp.name p.addrp.addr.state

24. 24 © Ellis Cohen 2001-2006 Creating Cell Objects INSERT INTO PersonTable VALUES ( 'STERN', Address( '11 Global Way', 'Hereville', MS, 39452 ) ) Cell Objects do not have OIDs REFs to Cell Objects are not allowed

25. 25 © Ellis Cohen 2001-2006 Object Type Methods CREATE TYPE AddrObj AS OBJECT ( street varchar(100), city varchar(40), state char(2), zip char(5), MEMBER FUNCTION toString RETURN varchar … ) CREATE TYPE PersonObj AS OBJECT( name varchar(30), addr Address ) CREATE TABLE PersonTable OF PersonObj SELECT name, addr.toString() FROM PersonTable

26. 26 © Ellis Cohen 2001-2006 Ordering by Object Types SELECT name FROM PersonTable ORDER BY addr How is an order defined on addresses? Oracle (e.g.) allows a single MAP member function to be defined for AddrObjs. It returns a primitive type, used as the basis of ordering MAP MEMBER FUNCTION getZip RETURN char(5) IS RETURN zip; END Oracle instead allows the ORDER member function; it compare two objects, returning -1 if the first is smaller 0 if they are equal 1 if the first is larger Order AddrObjs based on their zip values

27. 27 © Ellis Cohen 2001-2006 Selecting with Member Functions CREATE TABLE Positions( posid int, – id of the position coord Coordinate, – location of the position … ) SELECT posid FROM Positions WHERE coord.inRegion( 0, 0, 100, 100) > 0 CREATE TYPE Coordinate AS OBJECT x number, y number, MEMBER FUNCTION inRegion RETURN INT … – returns 1 if coordinate is within the specified region … )

28. 28 © Ellis Cohen 2001-2006 Type-Specific Indexing ORDB databases generally support type-specific indices InRegion queries can be implemented as the intersection of x and y range queries based on B- tree indices, however Coordinate-specific indices such as quadtree and R-tree indices select inRegion tuples much more quickly

29. 29 © Ellis Cohen 2001-2006 Nested Tables

30. 30 © Ellis Cohen 2001-2006 Nested Tables 23HRNY 31SALESLA ……… … deptno dname loc empls 3049SMITH…… 6471JONES…… 8187GOMEZ…… 2069SONI…… 8142EMEBI…… Purist approaches to ORDB's (e.g. Date) only allows Nested Tables (and other Contained Objects and Collections), but do NOT allow Row Objects and References.

31. 31 © Ellis Cohen 2001-2006 Nested Tables of Objects CREATE TYPE DeptEmpsObj As OBJECT ( deptno number(4), dname varchar(30), loc varchar(30), empls TABLE OF EmpObj ) CREATE TABLE DeptEmpsTable OF DeptEmpsObj PRIMARY KEY deptno SELECT dname FROM DeptEmpsTable d WHERE EXISTS( SELECT * FROM d.empls e WHERE e.job = 'SALESMAN') SELECT e.name FROM DeptEmpsTable d, d.empls e WHERE d.loc = 'BOSTON' List names of depts which have salesmen List employees of depts located in Boston Correlated table expressions allowed on nested tables Now, of those employees, determine how many have each kind of job

32. 32 © Ellis Cohen 2001-2006 Correlation Grouping Solution Of the employees in departments located in Boston, determine how many have each kind of job. SELECT e.job, count(*) FROM DeptEmpsTable d, d.empls e WHERE d.loc = 'BOSTON' GROUP BY e.job

33. 33 © Ellis Cohen 2001-2006 Nested Update Problem Nested Tables can be very efficient for some operations SELECT e.name FROM DeptEmpsTable d, d.empls WHERE d.loc = 'NY' AND e.job = 'ANALYST' How do you add 100 to the salary of these employees? You must use views!

34. 34 © Ellis Cohen 2001-2006 Nested Tables & Unnested Views 23HRNY 31SALESLA ……… … deptno dname loc empls 3049SMITH…… 6471JONES…… 8187GOMEZ…… 2069SONI…… 8142EMEBI…… 23HRNY3049SMITH…… 23HRNY6471JONES…… 23HRNY8187GOMEZ…… 31SALESLA2069SONI…… …………… deptno dname loc DeptEmpView DeptEmpsTable

35. 35 © Ellis Cohen 2001-2006 Views for Updating CREATE VIEW DeptEmpView AS SELECT d.deptno, d.name, d.loc, e.* FROM DeptEmpsTable d, d.empls e UPDATE DeptEmpView SET sal = sal + 100 WHERE loc = 'NY' AND job = 'ANALYST' Can we update deptno? UPDATE DeptEmpView SET deptno = 31 WHERE empno = 6471 Updating deptno means moving the employee from one nested table to another. Might be supported in an ORDB system, but perhaps it would be better for Emps & Depts to be the actual tables, and to create a nested table view

36. 36 © Ellis Cohen 2001-2006 Result Sets with Nested Tables Given Depts (only dept info) and Emps (only employee info, except that Emps.deptno references Depts) Generate a result set: each tuple corresponds to each of the departments – it contains the name of the department, and a table of the names of each employee in the department. SELECT d.dname, TABLE( SELECT ename FROM Emps e WHERE e.deptno = d.deptno ) FROM Depts d Given Depts and Emps, create a view that corresponds to DeptEmpsTable (with its nested table of employees)

37. 37 © Ellis Cohen 2001-2006 Creating Nested Table Views CREATE VIEW DeptEmpsTableView OF DeptObj WITH OBJECT OID (deptno) AS SELECT d.*, TABLE( SELECT empno, … FROM Emps e WHERE d.deptno = e.deptno) AS empls FROM Depts d Oracle also allows definition of the original DeptEmpsTable, with the combined nested tables of all the Employees implemented as a single query-able table Given Depts and Emps, create a view that corresponds to DeptEmpsTable (with its nested table of employees)

38. 38 © Ellis Cohen 2001-2006 Nested Result Sets from References Generate a result set: each tuple contains a department name and a table of the names of the dept employees 30SALES… 10ACCOUNTING… 50SUPPORT… 99PARTY… deptno dname loc DeptTable empno name … dept 7499ALLEN... 7654MARTIN… 7698BLAKE… 7839KING… 7844TURNER… 7986STERN… EmpTable

39. 39 © Ellis Cohen 2001-2006 Result Set Solution SELECT d.dname, TABLE( SELECT name FROM EmpTable e WHERE e.dept = REF(d) ) FROM DeptTable d Generate a result set: each tuple contains a department name and a table of the names of the dept employees Generate the same result set, but given DeptEmpsTable (each dept has empls, a nested table of employees)

40. 40 © Ellis Cohen 2001-2006 Related Nested Result Set SELECT d.dname, TABLE( SELECT name FROM d.empls ) FROM DeptEmpsTable d Notice that SELECT d.dname, d.empls.name FROM DeptEmpsTable d is incorrect! Generate a result set: each tuple contains a department name and a table of the names of the dept employees, given DeptEmpsTable

41. 41 © Ellis Cohen 2001-2006 Cross Referencing 30SALES 10ACCOUNTING 50SUPPORT deptno dname empls DeptTable empno name … dept 7499ALLEN... 7654MARTIN… 7698BLAKE… 7839KING… 7844TURNER… 7986STERN… EmpTable Suppose we keep the employees in a separate table And every department contains a table containing just references to the employees in that department

42. 42 © Ellis Cohen 2001-2006 Nested Tables of Refs CREATE TYPE RefEmp AS REF EmpObj SCOPE EmpTable; CREATE TYPE DeptObj AS OBJECT ( deptno number(4), dname varchar(30), loc varchar(30), empls TABLE OF RefEmp ) CREATE TABLE DeptTable OF DeptObj PRIMARY KEY deptno SELECT dname FROM DeptTable d WHERE EXISTS( SELECT * FROM d.empls e WHERE e.job = 'SALESMAN') SELECT e.name FROM DeptTable d, d.empls e WHERE d.loc = 'Boston'