Download presentation
Presentation is loading. Please wait.
Published byLydia Nelson Modified over 9 years ago
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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.