Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Advanced Database Topics Copyright © Ellis Cohen 2002-2005 Modeling, Storing & Querying Object-Oriented Data These slides are licensed under a Creative.

Similar presentations


Presentation on theme: "1 Advanced Database Topics Copyright © Ellis Cohen 2002-2005 Modeling, Storing & Querying Object-Oriented Data These slides are licensed under a Creative."— Presentation transcript:

1 1 Advanced Database Topics Copyright © Ellis Cohen 2002-2005 Modeling, Storing & Querying Object-Oriented Data 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 2002-2005 Overview of Object / Database Topics Modeling OO Data (ODL) Querying OO Data (OQL) OO Persistent Storage (OODBs) Client Access to Persistent OO Data Modifying Persistent OO Data Object-Relational Mapping Integrated Access to Relational and OO Databases OORDBs

3 3 © Ellis Cohen 2002-2005 Topics for This Lecture Object Modeling & Mapping ODL (Object Definition Language) Introduction to OQL (Object Query Language) OODB's (Object-Oriented Databases) Inheritance in ODL Basic OQL OQL Functions and Named Queries Subqueries Collection Operations Partitioning Flattening

4 4 © Ellis Cohen 2002-2005 Object Modeling & Mapping

5 5 © Ellis Cohen 2002-2005 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 2002-2005 The Object Database Challenge Why not model persistent data the same way we represent program data – as collections of objects which point to one another? If we model data as objects, can we design a query language as powerful and robust as SQL?

7 7 © Ellis Cohen 2002-2005 Object Model Object Classes & Instances –Correspond to entity classes and instances Collections Set (of specified type, no duplicates) Bag (of specified type, duplicates) List (of specified type, ordered, duplicates) Array (efficiently indexed list, names are integers or enumerated values) Dictionary (both values & names have a specified type ) Pointers between objects correspond to relationships

8 8 © Ellis Cohen 2002-2005 Object Mapping Relational Mapping Mapping an ER model to a Relational Model Object Mapping Mapping an ER model to an Object Model Dept works for deptno dname empno name job addr Employee manages

9 9 © Ellis Cohen 2002-2005 Representing an Employee Employee empno: int name: string job: string addr: Address dept: ptr to a Dept (generally called a reference)

10 10 © Ellis Cohen 2002-2005 Employee References its Dept dept1 dept2 dept3 emp1 emp3 emp5 emp4 emp2 dept

11 11 © Ellis Cohen 2002-2005 Representing a Dept Dept deptno: int dname: string empls: Collection of ptrs to Employee

12 12 © Ellis Cohen 2002-2005 Dept References its Employees dept1 dept2 dept3 emp1 emp3 emp5 emp4 emp2 empls

13 13 © Ellis Cohen 2002-2005 Mapping Decision for Object Models A relationship between two ER classes A and B can be represented in 3 different ways 1.ptrs from A's to B's 2.ptrs from B's to A's 3.both (one is the inverse of the other) In mapping an ER model to an Object model, you may be able to decide how to map each relationship

14 14 © Ellis Cohen 2002-2005 Inverse Relationships dept1 dept2 dept3 emp1 emp3 emp5 emp4 emp2 empls dept

15 15 © Ellis Cohen 2002-2005 ODL (Object Definition Language)

16 16 © Ellis Cohen 2002-2005 Object Definition Language (ODL) class Employee { attribute int empno; attribute string name; attribute string job; attribute Address addr; relationship Dept dept inverse Dept::empls; } class Dept { attribute int deptno; attribute string dname; relationship Set empls inverse Employee::dept;

17 17 © Ellis Cohen 2002-2005 ODL Exercises 1.Represent the manages relationship in ODL. 2.Add a Project class. A project has multiple employees; an employee can be assigned to multiple project. Represent this in the ER diagram and in ODL. 3.There is a relationship between employees who are spouses. Represent this in the ER diagram and in ODL.

18 18 © Ellis Cohen 2002-2005 Representing Manages class Employee { attribute int empno; attribute string name; attribute string job; attribute Address addr; relationship Dept dept inverse Dept::empls; relationship Employee mgr inverse managees; relationship Set managees inverse mgr; } class Dept { attribute int deptno; attribute string dname; relationship Set empls inverse Employee::dept;

19 19 © Ellis Cohen 2002-2005 Updated ER Model Dept works for deptno dname empno name job addr Employee manages Project pno pname spouse

20 20 © Ellis Cohen 2002-2005 Representing Projects & Spouses class Employee { attribute int empno; attribute string name; attribute string job; attribute Address addr; relationship Dept dept inverse Dept::empls; relationship Employee mgr inverse managees; relationship Set managees inverse mgr; relationship Employee spouse inverse spouse; relationship Set assignments inverse Project::members; } class Project { attribute int pno; attribute string pname; relationship Set members inverse Employee::assignments; }

21 21 © Ellis Cohen 2002-2005 About Relationships Some object systems automatically maintain inverse relationships. In Employee relationship Set assignments inverse Project::members; When a project is added to an employee's assignments, the employee can automatically be added to that project's members. 1:M and M:N relationships can be represented by any type of collection, not just by a set. In Employee relationship List assignments inverse Project::members; This allows each employee's projects to be maintained in some order; e.g. in order of importance to that employee. Makes it harder to automatically maintain inverse relationships (if a members is added to a project, in what order should that project be added to the employee's assignments)

22 22 © Ellis Cohen 2002-2005 Containment vs Reference Example 111-33-6174SMITH Kidney23 cm Spleen25 cm Liver29 cm 111-33-6174SMITH Kidney23 cm Spleen25 cm Liver29 cm Person w OrganStruct attribute Containment Reference (sharable)

23 23 © Ellis Cohen 2002-2005 Modeling Containment vs Reference Relationships always represent sharable references to objects Attributes usually hold primitive types Attributes may hold objects (or structs or collections containing objects) Is an attribute contained in its parent object or does it hold a reference? If an attribute is contained in its parent object, can some other attribute share it, i.e. hold a reference to it? Approaches differ from system to system. Keywords may be used to specify the approach We'll assume that attributes cannot be shared

24 24 © Ellis Cohen 2002-2005 1st & 2nd Class Objects 1 st Class Objects Managed independently Accessed through relationships 2 nd Class Objects Managed by a parent object Accessed through attributes

25 25 © Ellis Cohen 2002-2005 Objects & Methods class Rectangle { attribute Point topleft; attribute Point botright; float height() returns float; float width() returns float; float area() returns float; boolean overlaps( Rectangle rect ) } Classes can also declare methods, whose definitions are stored as part of the database. Depending upon the database, these may be classic "stored procedures", meant to be executed at the database (esp for functions used in queries), or could be meant to be returned to the client and executed on the client-side

26 26 © Ellis Cohen 2002-2005 Introduction to OQL (Object Query Language)

27 27 © Ellis Cohen 2002-2005 Referencing / Navigation Given an employee e e.name – e's name e.dept – department of e e.dept.deptno – the # of e's dept e.dept.dname – the name of e's dept Given a department d d.empls – the set of employees who work in dept d d.empls.age – NOT LEGAL because d.empls is a collection

28 28 © Ellis Cohen 2002-2005 OQL (Object Query Language) Given a department d d.empls the collection of employees who work in dept d SELECT e.empno FROM e IN d.empls the employee numbers of the employees who work in department d SELECT e.empno, e.name FROM e IN d.empls the employee numbers & names of the employees who work in department d OQL SELECT iterates through the elements of a collection

29 29 © Ellis Cohen 2002-2005 Extents How do you iterate through all the persistent employees? We can associate an extent with a class, which corresponds to the set of persistent instances in that class.

30 30 © Ellis Cohen 2002-2005 ODL with Extents class Employee (extent emps) { attribute int empno; attribute string name; attribute string job; attribute Address addr; relationship Dept dept inverse Dept::empls; relationship Employee mgr inverse managees; relationship Set managees inverse mgr; } class Dept (extent depts) { attribute int deptno; attribute string dname; relationship Set empls inverse Employee::dept; }

31 31 © Ellis Cohen 2002-2005 Collections and Relationships depts emps dept1 dept2 dept3 emp1 emp3 emp5 emp4 emp2 empls dept

32 32 © Ellis Cohen 2002-2005 Queries involving Extents SELECT e.empno FROM e IN emps WHERE e.name = "SMITH" SELECT e.empno, e.name FROM e IN emps WHERE e.job = "CLERK"

33 33 © Ellis Cohen 2002-2005 Navigation Eliminates Joins SQL: SELECT e.name, d.dname FROM Emps e NATURAL JOIN Depts d WHERE d.loc = 'Boston' OQL: SELECT e.name, e.dept.dname FROM e IN emps WHERE e.dept.loc = "Boston" Return the name of every employee and the name of their department, if their department is located in Boston

34 34 © Ellis Cohen 2002-2005 Still Need Ordinary Joins SELECT e.name FROM e IN emps, s IN starbucks WHERE e.zip = s.zip Generate the names of employees who live in zipcodes where there is a Starbucks SELECT e1.name, e2.name FROM e1 IN emps, e2 IN emps WHERE e1.empno < e2.empno AND abs(e1.sal - e2.sal) <= 100 Generate pairs of employees whose salaries are within $100 of one another

35 35 © Ellis Cohen 2002-2005 OODB's (Object-Oriented Databases)

36 36 © Ellis Cohen 2002-2005 Object & Database Notions Databases Persistence Storage Optimization Indexing Queries (SQL) Query Optimization Constraints & Triggers Transactions Backup & Recovery Role-based Security Object Systems Encapsulation Object Types Attributes Methods Inheritance Polymorphism Object Identity References Navigation Collections Versioning

37 37 © Ellis Cohen 2002-2005 Extents and Collections Class' Extent An automatically maintained collection of persistent 1 st class objects of that class (creating a new persistent 1 st class object automatically adds it to its class's extent) A class need not have an associated extent An OODB consists of –persistent objects –their extents –other explicitly defined persistent collections populace person-1 person-2 person-3 … coolpeople How would you model this in an RDB?

38 38 © Ellis Cohen 2002-2005 RDB Persistent Collections 40694… 15129… 30276… 81107… 60019… persno name Populace 40694 30276 81107 persno CoolPeople 40694…T 15129…F 30276…T 81107…T 60019…F persno name iscool Populace Could use the ROWID

39 39 © Ellis Cohen 2002-2005 RDB Identity 30SALES 10ACCOUNTING 50SUPPORT deptno dname Depts empno name addr deptno 7499ALLEN...30 7654MARTIN…30 7844TURNER…30 7212LAVICH… 7698BLAKE…10 7986STERN…10 Emps Identity of an "object" is determined by its primary key, and "references" are represented by foreign keys. What happens if a department's primary key changes?

40 40 © Ellis Cohen 2002-2005 OODB Identity empno: 7698 name : BLAKE addr : … dept : 3A47215FE empno: 7986 name : STERN addr : … dept : 3A47215FE deptno: 10 dname : ACCOUNTING Note: only showing Employee.dept, not its inverse, Dept.empls 3A47215FE B67EE3CD4 5C7780112 Every object has an OID (an Object ID) which uniquely identifies it. A reference can be implemented by a field hold the OID of the referenced object

41 41 © Ellis Cohen 2002-2005 Object Identity Models Primary Key Identifies row in an RDB Can be changed or reused Not usually globally unique Reference via foreign key, may not necessarily always refer to same row OID (Object ID) Uniquely identifies 1 st class object, independent of all of its values (e.g. my axe) Can't be changed; also can't be reused (unlike ROWIDs) Often is globally unique Reference holds (directly or indirectly) the OID, and always refers/points to the same object (why references are also called pointers)

42 42 © Ellis Cohen 2002-2005 OODB Storage Representation All objects are stored independently Could dramatically increase the cost of a full scan through an extent (OODB equivalent of a table) Many OODB's automatically cluster together (on the same page) objects that are used together (e.g. a dept & all its employees) Some OODB's allow user to explicitly list/describe objects that should be clustered together.

43 43 © Ellis Cohen 2002-2005 Extents & Objects in ODB's 622AuditingCHICAGO… deptno dname loc … AAAGDxAAB AAAH9EAAD depts Objects from different extents/classes may all share the same block! Actually, objects are identified by OIDs, which are not quite ROWIDs

44 44 © Ellis Cohen 2002-2005 Extents with Keys class Employee (extent emps, key empno) { attribute int empno; attribute string name; attribute string job; attribute Address addr; relationship Dept dept inverse Dept::empls; } class Dept (exptent depts, key deptno) { attribute int deptno; attribute string dname; relationship Set empls inverse Employee::dept; } Keys are optional - indicate unique attributes Relationship between objects is modeled directly, not via correspondence between primary and foreign keys Relationships reference objects via their OIDs

45 45 © Ellis Cohen 2002-2005 Indexing (non-standard) Some OODB's support creation of indices on extents & other persistent collections Assuming emps is the extent for Employee Attribute index Create index sal on emps Multi-attribute index Create index job, sal on emps Indexing can be especially useful when used with persistent collections other than extents

46 46 © Ellis Cohen 2002-2005 Inheritance in ODL

47 47 © Ellis Cohen 2002-2005 ODL Class Extension class Person (extent populace) { attribute int persid, attribute string name, attribute int age, attribute string kind, … } class Employee extends Person (extent emps) { attribute int empno, … } How would you model this in an RDB? An Employee has the attributes/relationships/methods specified for Employee plus those for Person Person Employee persid name age kind empno …

48 48 © Ellis Cohen 2002-2005 RDBs vs OODBs 40694…… 15129…… 30276…… 81107…… 60019…… persid name age Persons 40694……… 30276……… 81107……… persid empno job … Emps populace person-1 emp-1 emp-2 … emps Some persons are employees

49 49 © Ellis Cohen 2002-2005 Subclass Checking Problem Suppose coolpeople is a persistent Set. Some of the persons in coolpeople are Employees. Write the SQL and then the OQL to list the names of all the employees in coolpeople.

50 50 © Ellis Cohen 2002-2005 SQL Subclass Checking SELECT p.name FROM Persons NATURAL JOIN CoolPersons NATURAL JOIN Employee e or SELECT p.name FROM Persons NATURAL JOIN CoolPersons WHERE p.isEmployee = 'T'

51 51 © Ellis Cohen 2002-2005 OQL Subclass Checking SELECT p.name FROM p IN coolpeople WHERE p.isEmployee Many object systems have a built-in mechanism for checking subclasses e.g. SELECT p.name FROM p IN coolpeople WHERE p INSTANCE OF Employee Unfortunately, OQL does not have such a standard mechanism Not standard OQL has boolean attributes

52 52 © Ellis Cohen 2002-2005 Subclass Casting Problem Suppose coolpeople is a persistent Set. Some of the persons in coolpeople are Employees. Write the OQL to list the employee numbers of all the employees in coolpeople.

53 53 © Ellis Cohen 2002-2005 Subclass Casting Non-Solution These don't work. Why not? SELECT p.empno FROM p IN coolpeople WHERE p.isEmployee Or, in a system with INSTANCE OF SELECT p.empno FROM p IN coolpeople WHERE p INSTANCE OF Employee

54 54 © Ellis Cohen 2002-2005 Subclass Casting What's the problem with SELECT p.empno FROM p IN coolpeople WHERE p.isEmployee coolpeople is a Set, so p identifies a Person instance. But Persons don't have an empno field, so this query will not compile. We need to claim that the only p's that satisfy the WHERE clause will be Employees. If p is an Employee, it will have an empno field. This is accomplished via casting: SELECT ((Employee)p).empno FROM p IN coolpeople WHERE p.isEmployee

55 55 © Ellis Cohen 2002-2005 ODL Classes A class defines attributes, relationships & methods. A class may extend another class (its immediate superclass) by defining attributes, relationships and methods in addition to those of its superclass. A class may only extend a single class, but that class may also extend a class (ad nauseum) Classes are instantiable – i.e. you can create an object of the specified class. It will have the attributes & relationships defined by its class (including those of its superclasses). Creating an instance of a class adds a reference for the instance to the class's extent (if it has one), and to the extents of its superclasses.

56 56 © Ellis Cohen 2002-2005 ODL Interfaces An interface also defines attributes, relationships & methods. An interface may inherit from any number of interfaces, adding attributes, relationships and methods of all the interfaces it inherits from. Interfaces are NOT instantiable – i.e. you cannot create an object of the specified interface, and they do not have extents (though this might sometimes be convenient) A class may be specified to implement any number of interfaces. This is a promise that the class defines (directly or through extension) all the attributes, relationships and methods defined by all the interface it implements.

57 57 © Ellis Cohen 2002-2005 Interfaces & Classes interface Student { attribute string college, attribute string program, attribute string year } Class TA extends Person : Student { … } A TA extend Person, and also implements the Student interface.

58 58 © Ellis Cohen 2002-2005 Basic OQL

59 59 © Ellis Cohen 2002-2005 SQL vs OQL SQL returns –result sets convertible to tables and sometimes to sets or scalar values –by searching through tables –using joins to search through multiple tables OQL returns –collections of elements convertible sometimes to a single element –by searching through collections –using navigation (and sometimes joins) to search through multiple collections

60 60 © Ellis Cohen 2002-2005 Selection as Iteration Iterate through a collection Given Bag ages SELECT a+5 FROM a IN ages WHERE a > 20  Bag If ages is the bag containing {5, 26,42,8,26}, the result will be the bag containing {31,47,31}

61 61 © Ellis Cohen 2002-2005 Selecting From Collections Given Set emps SELECT e.name FROM e IN emps WHERE e.age > 40  Bag (perhaps should return Set if name is a key) Given List rankemps SELECT e.name FROM e IN rankemps WHERE e.age > 40  Bag (perhaps should return List ) Return the names of the employees in rankemps who are older than 40 Return the names of the employees in emps who are older than 40

62 62 © Ellis Cohen 2002-2005 Selecting Collection Elements Given Set emps SELECT e FROM e IN emps WHERE e.age > 40  Set Given List rankemps SELECT e FROM e IN emps WHERE e.age > 40  Bag (perhaps should return List ) Return the employees in emps who are older than 40 Return the names of the employees in emps who are older than 40

63 63 © Ellis Cohen 2002-2005 Generating Sets, Lists & Bags SELECT e.name FROM e IN emps WHERE e.age > 40  Bag SELECT DISTINCT e.name FROM e IN emps WHERE e.age > 40  Set SELECT e.name FROM e IN emps WHERE e.age > 40 ORDER BY e.age  List distinct( SELECT e.name FROM e IN emps WHERE e.age > 40)

64 64 © Ellis Cohen 2002-2005 Generating Collections of Structs SELECT who: e.name, e.age FROM e IN emps WHERE e.age > 40  Bag SELECT struct( who: e.name, age: e.age ) FROM e IN emps WHERE e.age > 40 Return the names and ages (bundled up in a struct) of the employees in emps who are older than 40 Renames field The struct can be specified explicitly, but then all fields must be explicitly named

65 65 © Ellis Cohen 2002-2005 Basic OQL Problem Suppose Project (extent projs) has attribute string pname -- the name of the project relationship Employee pmgr -- the employee who manages the project List the names of projects whose project manager has the job of ANALYST List the names of project managers who are analysts Neither query requires a join!

66 66 © Ellis Cohen 2002-2005 Basic OQL Solution Suppose Project (extent projs) has attribute string pname and relationship Employee pmgr List the names of projects whose project manager has the job ANALYST SELECT p.pname FROM p IN projs WHERE p.pmgr.job = "ANALYST" List the names of project managers who are analysts SELECT DISTINCT p.pmgr.name FROM p IN projs WHERE p.pmgr.job = "ANALYST"

67 67 © Ellis Cohen 2002-2005 Generating Objects SELECT struct( name: e.name, age: e.age ) FROM e IN emps WHERE e.age > 40  Bag SELECT Person( name: e.name, age: e.age - 20 ) FROM e IN emps WHERE e.age > 40  Bag Clone a younger model

68 68 © Ellis Cohen 2002-2005 OQL Functions and Named Queries

69 69 © Ellis Cohen 2002-2005 Aggregate/Collection Functions SQL: SELECT avg(sal) FROM Emps SELECT count(*) FROM Emps OQL: avg( SELECT e.sal FROM e IN emps ) count( emps ) Return the average salary of the employees Return the number of the employees In OQL aggregate functions operate on collections

70 70 © Ellis Cohen 2002-2005 Aggregating Navigated Collections SQL: SELECT d.dname, (SELECT count(*) FROM Emps e WHERE e.deptno = d.deptno) AS knt FROM Depts d OQL: SELECT d.dname, knt: count(d.empls) FROM d IN depts

71 71 © Ellis Cohen 2002-2005 Collection Functions exists( col ) whether a collection has at least one element unique( col ) whether a collection has exactly one element element( col ) the one element in a collection w one element (returns UNDEFINED otherwise) pick( col ) – non-standard arbitrarily chooses an element of a collection (returns UNDEFINED if empty) distinct( col ) the set with all the distinct elements of the collection (i.e. with duplicates removed) flatten( col ) A flattened representation of a collection of collections SQL's NULL OQL's UNDEFINED

72 72 © Ellis Cohen 2002-2005 Operations on Lists/Arrays first( lst ), last( lst ) The first or last element of a list or an array. lst[nth] The n th element of a list or array. lst[n1:n2] The n1 th through n2 th elements of a list or array. lst1 + lst2 The concatenation of lst1 and lst2 listToSet( lst ) A set with the same elements as the list

73 73 © Ellis Cohen 2002-2005 Access to Dictionaries (non-standard!) dict[nam] The element of a dictionary named nam, for example mydict["joe"] dictionaryContents( dict ) A set with the contents of the dictionary elements dictionaryKeys( dict ) A set with the keys of the dictionary elements

74 74 © Ellis Cohen 2002-2005 Named Queries DEFINE OldEmps as SELECT e FROM e IN emps WHERE e.age >= 30 SELECT x.name, x.job FROM x IN OldEmps Define OldEmps as employees 30 or older OQL does not have views

75 75 © Ellis Cohen 2002-2005 Views vs Named Queries In SQL, Views are used –As functions/macros (using view expansion) –To limit modifications –For access control If OQL is not used for modifications & access control, then we just need support for macros/functions Allows us to treat named queries as macros/functions, with parameters

76 76 © Ellis Cohen 2002-2005 Parameterized Named Queries DEFINE AgedEmps( minage ) as SELECT e FROM e IN emps WHERE e.age >= minage SELECT x.name, x.job FROM x IN AgedEmps( 30 ) Define AgedEmps as employees minage or older

77 77 © Ellis Cohen 2002-2005 Subqueries & Correlation

78 78 © Ellis Cohen 2002-2005 Subqueries SELECT m.name, m.job FROM m IN (SELECT e FROM e IN emps WHERE e.age >= 30) SELECT e.name FROM e IN emps WHERE e.age = min( SELECT e.age FROM e IN emps) SELECT d.dname FROM d IN depts WHERE 25 < avg( SELECT e.age FROM e IN d.empls) What do these do?

79 79 © Ellis Cohen 2002-2005 Subquery Answers List the name & job of employees who are 30 or older SELECT m.name, m.job FROM m IN (SELECT e FROM e IN emps WHERE e.age >= 30) List the names of all employees who have the same age as the youngest employee SELECT e.name FROM e IN emps WHERE e.age = min( SELECT e.age FROM e IN emps) List the names of departments whose average employee age is over 25 SELECT d.dname FROM d IN depts WHERE 25 < avg( SELECT e.age FROM e IN d.empls)

80 80 © Ellis Cohen 2002-2005 Generating Collections SELECT d.dname, d.empls FROM d IN depts WHERE d.loc <> "BOSTON"  Bag empls )> SELECT d.dname, enames: (SELECT e.name FROM e IN d.empls) FROM d IN depts WHERE d.loc <> "BOSTON"  Bag enames )> What's the difference between these two?

81 81 © Ellis Cohen 2002-2005 Generating Collections Solution SELECT d.dname, d.empls FROM d IN depts WHERE d.loc <> "BOSTON" For each department not in Boston, generates the name of the department, along with the set of that department's employees SELECT d.dname, enames: (SELECT e.name FROM e IN d.empls) FROM d IN depts WHERE d.loc <> "BOSTON" For each department not in Boston, generates the name of the department, along with the set of the names of that department's employees Note: enames: d.empls.name is ILLEGAL!

82 82 © Ellis Cohen 2002-2005 Correlated Query Problem SQL: SELECT e.name, d.dname FROM Emps e NATURAL JOIN Depts d Return the name of every employee and the name of their department, for employees who work for departments How would you write this in OQL?

83 83 © Ellis Cohen 2002-2005 Correlated Query Solutions SELECT e.name, e.dept.dname FROM e IN emps WHERE is_defined( e.dept ) –Lists every employee & their dept –OQL: is_defined ~ SQL: IS NOT NULL needed because some employees may not be in depts SELECT e.name, d.dname FROM e IN emps, d IN depts WHERE e.dept = d –Using an OQL join SELECT e.name, d.dname FROM d IN depts, e IN emps WHERE e IN d.empls –Also an OQL join

84 84 © Ellis Cohen 2002-2005 Correlated Joins SELECT e.name, d.dname FROM d IN depts, e IN emps WHERE e IN d.empls SELECT e.name, d.dname FROM d IN depts, e IN d.empls -- emps not needed

85 85 © Ellis Cohen 2002-2005 Correlated Collection Problem Suppose Employee (extent emps) has relationship Set projsManaged Use it to List the names of projects whose managers are analysts Also, list the names of analysts who manage projects

86 86 © Ellis Cohen 2002-2005 Correlated Collection Solution Suppose Employee (extent emps) has relationship Set projsManaged List the names of projects whose managers are analysts SELECT p.pname FROM e IN emps, p IN e.projsManaged WHERE e.job = "ANALYST" List the names of employees who manage projects SELECT e.name FROM e IN emps WHERE exists( e.projsManaged )

87 87 © Ellis Cohen 2002-2005 Collection Operations

88 88 © Ellis Cohen 2002-2005 Navigation & Quantification SQL: SELECT d.dname FROM Depts d WHERE exists ( SELECT * FROM Emps WHERE e.deptno = d.deptno AND e.age > 50) OQL: SELECT d.dname FROM d IN depts WHERE exists ( SELECT e FROM e IN d.empls WHERE e.age > 50 ) SELECT d.dname FROM d IN depts WHERE EXISTS e IN d.empls : e.age > 50 List the names of the departments that have at least one employee older than 50

89 89 © Ellis Cohen 2002-2005 DISTINCT vs exists SQL: SELECT DISTINCT d.dname FROM Depts d NATURAL JOIN Emps e WHERE e.age > 50 OQL: SELECT DISTINCT d.dname FROM depts d, emps e WHERE e.dept =d AND e.age > 50 – Corresponds to SQL, but not the best way to write it in OQL SELECT DISTINCT d.dname FROM Depts d, d.empl e WHERE e.age > 50 List the names of the departments that have at least one employee older than 50

90 90 © Ellis Cohen 2002-2005 More Quantification SELECT d.dname FROM d IN depts WHERE FOR ALL e IN d.empls : e.age > 50 List the names of the departments that have exactly one employee is older than 50 List the names of the departments where all employees are older than 50 SELECT d.dname FROM d IN depts WHERE UNIQUE e IN d.empls : e.age > 50 SELECT d.dname FROM d IN depts WHERE unique ( SELECT e FROM e IN d.empls WHERE e.age > 50 )

91 91 © Ellis Cohen 2002-2005 Membership Class Person (extent populace) { attribute string ssno; attribute string name; attribute List kidnames; } List the names of the people who have a kid named "Yael" SELECT p.name FROM p IN populace WHERE EXISTS k IN p.kidnames : k = "Yael" SELECT p.name FROM p IN populace WHERE ("Yael" IN p.kidnames)

92 92 © Ellis Cohen 2002-2005 Collection Operators OQL has union, intersect & except operators Generate all employees in the accounting department who manage projects (SELECT e FROM e IN emps WHERE exists( e.projsManaged )) INTERSECT (SELECT d.empls FROM d IN depts WHERE d.dname = "ACCOUNTING") The result of these operators is a set if both operands are sets, else it is a bag

93 93 © Ellis Cohen 2002-2005 Collection Comparison SELECT p1, p2 FROM p1 IN populace, p2 IN populace WHERE p1.kidnames = p2.kidnames Find pairs of people whose kids have the same names in the same order Find pairs of people whose kids have the same names (in any order) SELECT p1, p2 FROM p1 IN populace, p2 IN populace WHERE listToSet(p1.kidnames) = listToSet(p2.kidnames) Bags & Sets c1 = c2 if c1 & c2 have same elements c1 < c2 if every element in c1 is in c2 Lists, Arrays, Dictionaries c1 = c2 if, for all j, c1[j] = c2[j] c1 < c2 if, for all j, c1[j] = c2[j] or c1[j] = nil (nil/undefined/null)

94 94 © Ellis Cohen 2002-2005 Partitioning

95 95 © Ellis Cohen 2002-2005 Partitioning emps 33 emp1 33 emp3 33 emp5 49 emp4 33 emp2 49 age 49 partition grpage partition grpage

96 96 © Ellis Cohen 2002-2005 Partitioning with GROUP BY SELECT grpage, partition FROM e IN emps GROUP BY grpage: e.age  Set )> SELECT partition FROM e IN emps GROUP BY grpage: e.age  Set > Group the employees by age Group by age but just return the partitions Suppose you wanted to calculate the # of employees at each age: In SQL: SELECT age AS grpage, count(*) AS knt FROM Employees GROUP BY age How would you get the equivalent result in OQL?

97 97 © Ellis Cohen 2002-2005 GROUP BY with Aggregation SQL: SELECT age AS grpage, count(*) AS knt FROM Emps GROUP BY age OQL: SELECT grpage, knt:count(partition) FROM e IN emps GROUP BY grpage: e.age  Set

98 98 © Ellis Cohen 2002-2005 Partition Selection SELECT grpage, grp: (SELECT p.name, p.job FROM p IN partition) FROM e IN emps GROUP BY grpage: e.age  Set )> Divide the employees by age, and collect together the name and job of all employees in each age group Can you write this without using GROUP BY?

99 99 © Ellis Cohen 2002-2005 Grouping without GROUP BY SELECT DISTINCT grpage: e.age, (SELECT ee.name, ee.job FROM ee in emps WHERE ee.age = e.age) FROM e IN emps

100 100 © Ellis Cohen 2002-2005 Grouping Problem For each job, produce the names of the departments in which some employee has that job (Use GROUP BY! Also consider a solution without using it)

101 101 © Ellis Cohen 2002-2005 Grouping Solution For each job, produce the names of the departments in which some employee has that job SELECT grpjob, jobdepts: (SELECT DISTINCT p.dept.dname FROM p IN partition) FROM e IN emps GROUP BY grpjob: e.job SELECT job, jobdepts: (SELECT d.dname FROM d IN depts WHERE EXISTS e IN d.empls : e.job = job) FROM job IN (SELECT DISTINCT e.job FROM e IN emps)

102 102 © Ellis Cohen 2002-2005 Grouping by Expression SELECT partition FROM e IN emps GROUP BY e.sal < 30000 Group together the employees who have low salaries (< 30000), and separately, the employees who have high salaries Group together people whose kids have exactly the same set of names SELECT partition FROM p IN populace GROUP BY listToSet(p.kidnames)  Set >

103 103 © Ellis Cohen 2002-2005 Group Restriction via Having SQL: SELECT job FROM Emps GROUP BY job HAVING count(*) > 1 OQL: SELECT e.job FROM e IN emps GROUP BY e.job HAVING count(partition) > 1 List jobs held by more than one employee Do in OQL: For each job that is held by more than one employee, list the employees in that job

104 104 © Ellis Cohen 2002-2005 Group Restriction Solution SELECT e.job, partition FROM e IN emps GROUP BY e.job HAVING count(partition) > 1 For each job that is held by more than one employee, list the employees in that job

105 105 © Ellis Cohen 2002-2005 Tricky Grouping Problem For each job, produce the names of the departments in which more than one employee holds that job (Use HAVING)

106 106 © Ellis Cohen 2002-2005 Tricky Grouping Solution For each job, produce the names of the departments in which more than one employee holds that job SELECT grpjob, jobdepts: (SELECT p.dname FROM p IN partition) FROM de IN (SELECT d.dname, e.job FROM d IN depts, e IN d.empls GROUP BY d.dname, e.job HAVING count(partition) > 1) GROUP BY grpjob: de.job SELECT grpjob, jobdepts: (SELECT dpt.dname FROM p IN partition GROUP BY dpt: p.dept HAVING count(partition) > 1 FROM e IN emps GROUP BY grpjob: e.job Note use of inner & outer partition

107 107 © Ellis Cohen 2002-2005 Flattening

108 108 © Ellis Cohen 2002-2005 Flattening Collection of Collections Result of Flattening

109 109 © Ellis Cohen 2002-2005 Flattening in OQL Generate the employees who are in jobs that are done by more than one employee flatten( SELECT partition FROM e IN emps GROUP BY e.job HAVING count(partition) > 1 )

110 110 © Ellis Cohen 2002-2005 Correlation & Flattening SELECT e.name, d.dname FROM d IN depts, e IN d.empls WHERE d.loc = "Boston" flatten( SELECT (SELECT e.name, d.dname FROM e IN d.empls) FROM d IN depts WHERE d.loc = "Boston" ) For all employees whose departments are located in Boston, generate their name and their department's name

111 111 © Ellis Cohen 2002-2005 Flattening Sublists DEFINE SizeDepts AS SELECT d.empls FROM d IN depts ORDER BY count(d.empls) desc flatten( SizeDepts[1:3] ) What does this do?

112 112 © Ellis Cohen 2002-2005 Flattening Sublists Solution DEFINE SizeDepts AS SELECT d.empls FROM d IN depts ORDER BY count(d.empls) desc flatten( SizeDepts[1:3] ) Generate the set of the employees who are in the three largest departments

113 113 © Ellis Cohen 2002-2005 Flattening and Transitive Closure DEFINE ManageClosure( e ) AS set( e ) -- a set consisting of e UNION flatten( SELECT ManageClosure(m) FROM m IN e.managees ) Define ManageClosure( e ) to consist of e plus all the employees who directly or indirectly report to e Note: e.managees is the set of employees that e directly manages


Download ppt "1 Advanced Database Topics Copyright © Ellis Cohen 2002-2005 Modeling, Storing & Querying Object-Oriented Data These slides are licensed under a Creative."

Similar presentations


Ads by Google