Object-orientation in databases

Chapter 9

Object-orientation in databases • SQL is algebraic at its core • The algebraic constitution is the source of its strength and weakness It is fruitful to think of it as the mother of query languages • We have seen that SQL works well for atomic data • The big question is … … how to extend the “SQL” for more complex forms of data

• In this chapter we add object-orientation to SQL • This leads to OQL – the Object Query Language • Our treatment is informal and not to be equated to the “standard” OQL • Our main focus is on how one improves linguistic interface for users

© Shashi K. Gadia, 2002-2015

117

9.2. Nested values • In the classical relational model ... • An (attribute) value is atomic • The main vehicle for navigation is A op B (e.g. e.DName = d.DName)

• A nested value is a relation • Example: consider the following schema for Emp relation Emp Name

DName

Salary

Child CName

Age

• An employee has a name, department, and a salary • The employee also has children, listed under the Child attribute • The value of the Child attribute is a relation • Each tuple of Child-relation gives the name and age of a child

• An instance is a nested relation: Emp Name

DName

Salary

John

Toys

50K

Twinkle

Shoes

45K

Child CName Jack Jill Hill Star

Age 18 15 10 17

• This scheme can be denoted as follows • Emp(Name, DName, Child(CName, Age))


119

9.3. Querying nested-relations • We discuss some queries informally • Example: List Names of employees in Toys department and info about their teenage children select e.Name, ( select * from e.Child c where 12 < c.Age and c.Age < 20) from Emp e where e.DName = ’Toys’

Name John

Child CName Jack Jill

Age 18 15

• Example: What does the following query return? select e.Name, c.CName, c.Age from Emp e, e.Child c where e.DName = ’Toys’ and (12 < c.Age and c.Age < 20)

Name John John

CName Jack Jill

Age 18 15

• How would we define union, difference, selection, projection, join, and possibly some new operators on nested relations? • About a dozen interesting papers on this in the database literature

120 : Object-orientation in databases


9.8. Personnel database: an object-oriented scheme • Put references and inheritance together Person (PersonID)

Dept (DeptID)

ID

DName

Name

Building

DOB

ManagedBy ISA

Emp (EmpID) Salary WorksIn ISA Manager (ManagerID)

• What is date of birth of John’s manager? select e.WorksIn.ManagedBy.DOB from Emp e where e.Name = ’John’

• Phrase e.WorksIn.ManagedBy.DOB is friendly • e is John’s tuple; e.WorksIn is John’s department • e.WorksIn.ManagedBy is John’s manager • The manager is an employee, hence also a person Therefore, e.WorksIn.ManagedBy.DOB is John’s manager’s DOB


125

9.9. Comparison with classical SQL • Recall the following (for date of birth of John’s manager) select e.WorksIn.ManagedBy.DOB from Emp e where e.Name = ’John’

• How will we do it in classical relational database setting? • A relational design for Personnel is as follows Person (Name, ID, DOB) Emp (EmID  Person.ID, DName  Dept, Salary) Dept (DName, ManagerID  Emp)

• We assume that there are no nulls

• In SQL “date of birth of John’s manager” is as follows select p2.DOB from Emp e1, Person p1, Dept d, Emp e2, Person p2 where p1.Name = "John" and e1.EmpID = p1.ID and e1.DName = d.DName and d.ManagerID = e2.EmpID and e2.EmpID = p2.ID

• A comparison of the two queries • A single variable e vs. five variables e1, p1, d, e2, and p2 • e.Name = "John" vs. e1.EmpID = p1.ID and p1.Name = "John" • e.WorksIn vs. e1.DName = d.DName • .ManagedBy vs. d.ManagerID = e2.EmpID and e2.EmpID = p2.ID

• Clearly … • … OQL is linguistically far more natural for users than plain SQL • But let us not forget that OQL is “derived” from SQL

126 : Object-orientation in databases
