Example Methods

• Can add a method declaration with a structured type.

method ageOnDate (onDate date)
returns interval year
• Method body is given separately.
create instance method ageOnDate (onDate date)
returns interval year
for CustomerType
begin
return onDate - self.dateOfBirth;
end
• We can now find the age of each customer:
select name.lastname, ageOnDate (current_date)
from customer
Example Type Inheritance
• Suppose that we have the following type definition for people:
create type Person
(name varchar(20),
address varchar(20))
• Using inheritance to define the student and teacher
types
create type Student
under Person
(degree varchar(20),
department varchar(20))
create type Teacher
under Person
(salary integer,
department varchar(20))
• Subtypes can redefine methods by using overriding
method in place of method in the method
TABLE INHERITANCE EXAMPLE
A car-rental company maintains a vehicle database for all
vehicles in its current
fleet. For all vehicles, it includes the vehicle identification
number, license number, manufacturer, model, date of
purchase, and color. Special data are included
for certain types of vehicles:
• Trucks: cargo capacity
• Sports cars: horsepower, renter age requirement
• Vans: number of passengers
• Off-road vehicles: ground clearance, drivetrain (four- or two-
wheel drive)
Construct an SQL:1999 schema definition for this database. Use
inheritance where appropriate.
Answer: For this problem, we use table inheritance. We
assume that MyDate,Color and DriveTrainType are pre-
defined types.
create type Vehicle
(vehicle-id integer,
license-number char(15),
model char(30),
purchase-date MyDate,
color Color)manufacturer char(30),
create table vehicle of type Vehicle
create table truck
(cargo-capacity integer)
under vehicle
 create table sportsCar
(horsepower integer
renter-age-requirement integer)
under vehicle
create table van
(num-passengers integer)
under vehicle
create table offRoadVehicle
(ground-clearance real
driveTrain DriveTrainType)
under vehicle
 NEW CHALLENGES IN
IMPLEMENTING ORDBMS
Storage and Access Methods:
 Large ADTs, like BLOBs, require special storage, typically in
a different location on disk from the tuples that contain them.
 Disk-based pointers are maintained from the tuples to the
objects they contain.
 Flexible disk layout mechanisms are required for structured
objects
 A complication arises with array types. Arrays are broken
into contiguous chunks, which are then stored in some order
on disk.
Indexing New Types:
 Users can be allowed for efficient access via indexes.
 It provides efficient indexes for ADT methods and
operators on structured objects.
 Template index structure – The Generalized Search
Tree(GiST) – allows most of the tree index structures
invented so far to be implemented with only a few lines of
user-defined ADT code.
 QUERY PROCESSING:
User-defined aggregation functions:
To register an aggregation function, a user must implement three methods, which we
call initialize, iterate and terminate.

Method Security:
ADTs give users the power to add code to the DBMS;
this power can be abused.

 A buggy or malicious ADT method can bring down the

database server or even corrupt the database.

One mechanism to prevent problems is to have the user

methods be interpreted rather than compiled.

Typical interpreted languages for this purpose include

Java and the procedural portions of SQL:1999.

An alternate mechanism is to allow user methods to be

compiled from a general-purpose programming language, such as C++.
Physical design and efficiency issues
• Query processing
• User defined aggregate functions (SQL defined may not be useful)
• ORDBMS allows registering new aggregate functions
• Security – external methods of ADT’s – can compromise the database
or crash (if its buggy).
• One solution – interpreted rather than compiled (Java and procedural
portions of SQL:1999).
• Run in different address space than the DBMS

• Method Caching
• Cache of input and output of methods

• Pointer Swizzling
• Technique to reduce cost of cached object

27
Single-Level v. Two-Level Storage Model

• Traditional programming languages lack built-in

support for many database features.
• Increasing number of applications now require
functionality from both database systems and
programming languages.
• Such applications need to store and retrieve large
amounts of shared, structured data.

29
Single-Level v. Two-Level Storage Model

• With a traditional DBMS, programmer has to:

• Decide when to read and update objects.
• Write code to translate between application’s object
model and the data model of the DBMS.
• Perform additional type-checking when object is read
back from database, to guarantee object will conform to
its original type.

30
Single-Level v. Two-Level Storage Model

• Difficulties occur because conventional DBMSs have

two-level storage model: storage model in memory,
and database storage model on disk.
• In contrast, OODBMS gives illusion of single-level
storage model, with similar representation in both
memory and in database stored on disk.
• Requires clever management of representation of
objects in memory and on disk (called “pointer
swizzling”).

31
Two-Level Storage Model for RDBMS

32
Single-Level Storage Model for OODBMS

33
Pointer Swizzling Techniques

The action of converting object identifiers (OIDs) to

main memory pointers.
• Aim is to optimize access to objects.
• Should be able to locate any referenced objects on
secondary storage using their OIDs.
• Once objects have been read into cache, want to
record that objects are now in memory to prevent
them from being retrieved again.

34
Pointer Swizzling Techniques

• Could hold lookup table that maps OIDs to memory

pointers.
• Pointer swizzling attempts to provide a more
efficient strategy by storing memory pointers in the
place of referenced OIDs, and vice versa when the
object is written back to disk.

35
Accessing an Object with a RDBMS

36
Accessing an Object with an OODBMS

37
 Chapter Outline
20.1 Overview of O-O Concepts
20.2 O-O Identity, Object Structure and Type
Constructors
20.3 Encapsulation of Operations, Methods and
Persistence
20.4 Type and Class Hierarchies and Inheritance
20.5 Complex Objects
20.6 Other O-O Concepts
20.7 Summary & Current Status
 Introduction

• Traditional Data Models : Hierarchical, Network (since mid-

60’s), Relational (since 1970 and commercially since 1982)
• Object Oriented (OO) Data Models since mid-90’s
• Reasons for creation of Object Oriented Databases
• Need for more complex applications
• Need for additional data modeling features
• Increased use of object-oriented programming languages
• Commercial OO Database products – several in the 1990’s, but
did not make much impact on mainstream data management
 History of OO Models and
Systems
• Languages: Simula (1960’s), Smalltalk (1970’s), C++
(late 1980’s), Java (1990’s)
• Experimental Systems: Orion at MCC, IRIS at H-P labs,
Open-OODB at T.I., ODE at ATT Bell labs, Postgres -
Montage - Illustra at UC/B, Encore/Observer at Brown
• Commercial OO Database products: Ontos,
Gemstone, O2 ( -> Ardent), Objectivity, Objectstore ( -
> Excelon), Versant, Poet, Jasmine (Fujitsu – GM)
 20.1 Overview of Object-Oriented
Concepts(1)
• MAIN CLAIM: OO databases try to maintain a
direct correspondence between real-world and
database objects so that objects do not lose their
integrity and identity and can easily be identified
and operated upon
• Object: Two components: state (value) and
behavior (operations). Similar to program variable
in programming language, except that it will
typically have a complex data structure as well as
specific operations defined by the programmer
 Overview of Object-Oriented
Concepts (2)

• In OO databases, objects may have an object structure of arbitrary

complexity in order to contain all of the necessary information that
describes the object.
• In contrast, in traditional database systems, information about a
complex object is often scattered over many relations or records,
leading to loss of direct correspondence between a real-world object
and its database representation.
 Overview of Object-Oriented
Concepts (3)

• The internal structure of an object in OOPLs includes the specification

of instance variables, which hold the values that define the internal
state of the object.
• An instance variable is similar to the concept of an attribute, except
that instance variables may be encapsulated within the object and
thus are not necessarily visible to external users
 Overview of Object-Oriented
Concepts (4)
• Some OO models insist that all operations a user can apply to an
object must be predefined. This forces a complete encapsulation of
objects.

• To encourage encapsulation, an operation is defined in two parts:

1. signature or interface of the operation, specifies the operation name and
arguments (or parameters).
2. method or body, specifies the implementation of the operation.
 Overview of Object-Oriented
Concepts (5)

• Operations can be invoked by passing a message to an object, which

includes the operation name and the parameters. The object then
executes the method for that operation.
• This encapsulation permits modification of the internal structure of an
object, as well as the implementation of its operations, without the
need to disturb the external programs that invoke these operations
 Overview of Object-Oriented
Concepts (6)

• Some OO systems provide capabilities for dealing with multiple

versions of the same object (a feature that is essential in design and
engineering applications).
• For example, an old version of an object that represents a tested and verified
design should be retained until the new version is tested and verified:
• very crucial for designs in manufacturing process control, architecture ,
software systems …..
 Overview of Object-Oriented
Concepts (7)

• Operator polymorphism: It refers to an operation’s ability to be

applied to different types of objects; in such a situation, an operation
name may refer to several distinct implementations, depending on
the type of objects it is applied to.

• This feature is also called operator overloading

 20.2 Object Identity, Object
Structure, and Type Constructors
(1)
• Unique Identity: An OO database system provides a unique identity to
each independent object stored in the database. This unique identity
is typically implemented via a unique, system-generated object
identifier, or OID
• The main property required of an OID is that it be immutable; that is,
the OID value of a particular object should not change. This preserves
the identity of the real-world object being represented.
 Object Identity, Object Structure, and Type
Constructors (2)

• Type Constructors: In OO databases, the state (current value) of a

complex object may be constructed from other objects (or other
values) by using certain type constructors.
• The three most basic constructors are atom, tuple, and set. Other
commonly used constructors include list, bag, and array. The atom
constructor is used to represent all basic atomic values, such as
integers, real numbers, character strings, Booleans, and any other
basic data types that the system supports directly.
 Object Identity, Object
Structure, and Type
Constructors (3)
• Example 1, one possible relational database state corresponding to COMPANY
schema
 Object Identity, Object
Structure, and Type
Constructors (4)
• Example 1 (cont.):
 Object Identity, Object
Structure, and Type
Constructors (5)
• Example 1 (cont.)
 Object Identity, Object
Structure, and Type
Constructors (6)
• Example 1 (cont.)
We use i1, i2, i3, . . . to stand for unique system-generated
object identifiers. Consider the following objects:
o1 = (i1, atom, ‘Houston’)
o2 = (i2, atom, ‘Bellaire’)
o3 = (i3, atom, ‘Sugarland’)
o4 = (i4, atom, 5)
o5 = (i5, atom, ‘Research’)
o6 = (i6, atom, ‘1988-05-22’)
o7 = (i7, set, {i1, i2, i3})
 Object Identity, Object
Structure, and Type
Constructors (7)
• Example 1(cont.)
o8 = (i8, tuple, <dname:i5, dnumber:i4, mgr:i9, locations:i7,
employees:i10, projects:i11>)
o9 = (i9, tuple, <manager:i12, manager_start_date:i6>)
o10 = (i10, set, {i12, i13, i14})
o11 = (i11, set {i15, i16, i17})
o12 = (i12, tuple, <fname:i18, minit:i19, lname:i20, ssn:i21, . . .,
salary:i26, supervi­sor:i27, dept:i8>)
...
 Object Identity, Object
Structure, and Type
Constructors (8)
Example 1 (cont.)
• The first six objects listed in this example represent atomic values. Object seven is a set-
valued object that represents the set of locations for department 5; the set refers to the
atomic objects with values {‘Houston’, ‘Bellaire’, ‘Sugarland’}. Object 8 is a tuple-valued
object that represents department 5 itself, and has the attributes DNAME, DNUMBER,
MGR, LOCATIONS, and so on.
 Object Identity, Object
Structure, and Type
Constructors (9)
Example 2:
This example illustrates the difference between the two definitions for
comparing object states for equality.
o1 = (i1, tuple, <a1:i4, a2:i6>)
o2 = (i2, tuple, <a1:i5, a2:i6>)
o3 = (i3, tuple, <a1:i4, a2:i6>)
o4 = (i4, atom, 10)
o5 = (i5, atom, 10)
o6 = (i6, atom, 20)
 Object Identity, Object
Structure, and Type
Constructors (10)
Example 2 (cont.):
In this example, The objects o1 and o2 have equal states, since their states at
the atomic level are the same but the values are reached through distinct
objects o4 and o5.

However, the states of objects o1 and o3 are identical, even though the
objects themselves are not because they have distinct OIDs. Similarly,
although the states of o4 and o5 are identical, the actual objects o4 and o5 are
equal but not identical, because they have distinct OIDs.
 Object Identity, Object
Structure, and Type
Constructors (11)
Figure 20.1 Representation of a DEPARTMENT complex object as a
graph
 Encapsulation of Operations,
Methods, and Persistence (4)
Figure 20.3 Adding operations to definitions of Employee
and Department
Encapsulation of Operations, Methods, and
Persistence (5)
Specifying Object Persistence via Naming and
Reachability:
• Naming Mechanism: Assign an object a unique persistent
name through which it can be retrieved by this and other
programs.
• Reachability Mechanism: Make the object reachable
from some persistent object.
• An object B is said to be reachable from an object A if a
sequence of references in the object graph lead from object A
to object B.
Encapsulation of Operations, Methods, and
Persistence (6)
Specifying Object Persistence via Naming and Reachability (cont.):
• In traditional database models such as relational model or EER model, all objects
are assumed to be persistent.

• In OO approach, a class declaration specifies only the type and operations for a
class of objects. The user must separately define a persistent object of type set
(DepartmentSet) or list (DepartmentList) whose value is the collection of
references to all persistent DEPARTMENT objects
Encapsulation of Operations, Methods, and
Persistence (7)

Note: The above figure is now called Figure 20.4 in Edition 4

 20.4 Type and Class Hierarchies
and Inheritance (1)
• Type (class) Hierarchy
• A type in its simplest form can be defined by giving it a type name and then listing
the names of its visible (public) functions
• When specifying a type in this section, we use the following format, which does
not specify arguments of functions, to simplify the discussion:
TYPE_NAME: function, function, . . . , function

Example:
PERSON: Name, Address, Birthdate, Age, SSN
 Type and Class Hierarchies
and Inheritance (2)

• Subtype: when the designer or user must create a new type that is
similar but not identical to an already defined type

• Supertype: It inherits all the functions of the subtype

 Type and Class Hierarchies
and Inheritance (3)

Example (1):
EMPLOYEE: Name, Address, Birthdate, Age, SSN, Salary, HireDate, Seniority
STUDENT: Name, Address, Birthdate, Age, SSN, Major, GPA
OR:
EMPLOYEE subtype-of PERSON: Salary, HireDate, Seniority
STUDENT subtype-of PERSON: Major, GPA
 Type and Class Hierarchies
and Inheritance (4)

Example (2):
Consider a type that describes objects in plane geometry, which may be defined
as follows:

GEOMETRY_OBJECT: Shape, Area, ReferencePoint

 Type and Class Hierarchies
and Inheritance (5)

• Example (2) (cont.):

Now suppose that we want to define a number of subtypes for the
GEOMETRY_OBJECT type, as follows:

RECTANGLE subtype-of GEOMETRY_OBJECT: Width, Height

TRIANGLE subtype-of GEOMETRY_OBJECT:
Side1, Side2, Angle
CIRCLE subtype-of GEOMETRY_OBJECT: Radius
 Type and Class Hierarchies
and Inheritance (6)

• Example (2) (cont.):

An alternative way of declaring these three subtypes is to specify the value of the
Shape attribute as a condition that must be satisfied for objects of each subtype:

RECTANGLE subtype-of GEOMETRY_OBJECT (Shape=‘rectangle’): Width,

Height
TRIANGLE subtype-of GEOMETRY_OBJECT (Shape=‘triangle’): Side1, Side2,
Angle
CIRCLE subtype-of GEOMETRY_OBJECT (Shape=‘circle’): Radius
 Type and Class Hierarchies
and Inheritance (7)

• Extents: In most OO databases, the collection of objects in an extent

has the same type or class. However, since the majority of OO
databases support types, we assume that extents are collections of
objects of the same type for the remainder of this section.
• Persistent Collection: It holds a collection of objects that is stored
permanently in the database and hence can be accessed and shared
by multiple programs
 Type and Class Hierarchies
and Inheritance (8)

• Transient Collection: It exists temporarily during the execution of a

program but is not kept when the program terminates
 Current Status
• OODB market not growing much per se. Currently around $250M as
opposed to the relational DB revenue upwards of $50B.
• O-O ideas are being used in a large number of applications, without
explicitly using the OODB platform to store data.
• Growth: O-O tools for modeling and analysis, O-O Programming
Languages like Java and C++
• Compromise Solution Proposed: Object Relational DB Management
(Informix Universal Server, Oracle 10i, IBM’s UDB, DB2/II …)
Overview of the Object Model ODMG
The Object Definition Language DDL
The Object Query Language OQL
Overview of C++ Binding
Object Database Conceptual Model
Summary
Chapter Objectives
• Discuss the importance of standards (e.g., portability, interoperability)
• Introduce Object Data Management Group (ODMG): object model,
object definition language (ODL), object query language (OQL)
• Present ODMG object binding to programming languages (e.g., C++)
• Present Object Database Conceptual Design
The Object Model of ODMG
• Provides a standard model for object databases
• Supports object definition via ODL
• Supports object querying via OQL
• Supports a variety of data types and type constructors
ODMG Objects and Literals
• The basic building blocks of the object model are
• Objects
• Literlas
• An object has four characteristics
1. Identifier: unique system-wide identifier
2. Name: unique within a particular database and/or program; it is optional
3. Lifetime: persistent vs transient
4. Structure: specifies how object is constructed by the type constructor and
whether it is an atomic object
ODMG Literals
• A literal has a current value but not an identifier
• Three types of literals
1. atomic: predefined; basic data type values (e.g., short, float, boolean,
char)
2. structured: values that are constructed by type constructors (e.g., date,
struct variables)
3. collection: a collection (e.g., array) of values or objects
Object Inheritance Hierarchy
Atomic Objects
• Atomic objects are user-defined objects and are defined via keyword
class
• An example:
class Employee (extent all_emplyees key ssn) {
attribute string name;
attribute string ssn;
attribute short age;
relationship Dept works_for;
void reassign(in string new_name);
}
Class Extents
• An ODMG object can have an extent defined via a class declaration
• Each extent is given a name and will contain all persistent objects
of that class
• For Employee class, for example, the extent is called
all_employees
• This is similar to creating an object of type Set<Employee> and
making it persistent
Class Key
• A class key consists of one or more unique attributes
• For the Employee class, the key is ssn
Thus each employee is expected to have a unique ssn
• Keys can be composite, e.g.,
(key dnumber, dname)
ODMG Interface
• An interface is a specification of the abstract behavior of an object
type
• State properties of an interface (i.e., its attributes and relationships)
cannot be inherited from
• Objects cannot be instantiated from an interface
ODMG Class
• A class is a specification of abstract behavior and state of an object
type
• A class is Instantiable
• Supports “extends” inheritance to allow both state and behavior
inheritance among classes
• Multiple inheritance via “extends” is not allowed
Object Definition Language
• ODL supports semantics constructs of ODMG
• ODL is ndependent of any programming language
• ODL is used to create object specification (classes and interfaces)
• ODL is not used for database manipulation
ODL Examples (1)
A Very Simple Class
• A very simple, straightforward class definition (all examples are based on the
university schema presented in Chapter 4 and graphically shown on page 680):
class Degree {
attribute string college;
attribute string degree;
attribute string year;
};
ODL Examples (2)
A Class With Key and Extent
• A class definition with “extent”, “key”, and more elaborate attributes;
still relatively straightforward

class Person (extent persons key ssn) {

attribute struct Pname {string fname …} name;
attribute string ssn;
attribute date birthdate;
…
short age();
}
ODL Examples (3)
A Class With Relationships
• Note extends (inheritance) relationship
• Also note “inverse” relationship

Class Faculty extends Person (extent faculty) {

attribute string rank;
attribute float salary;
attribute string phone;
…
relationship Dept works_in inverse Dept::has_faculty;
relationship set<GradStu> advises inverse GradStu::advisor;
void give_raise (in float raise);
void promote (in string new_rank);
};
Inheritance via “:” – An Example

interface Shape {
attribute struct point {…} reference_point;
float perimeter ();
…
};

class Triangle: Shape (extent triangles) {

attribute short side_1;
attribute short side_2;
…
};
 Defining a Class
• class – keyword for
defining classes
• attribute – keyword
for attributes
• operations – return
type, name,
parameters in
parentheses
• relationship – keyword
for establishing
relationship

94
 Defining an Attribute
• Value can be either:
• Object identifier OR Literal
• Types of literals
• Atomic – a constant that cannot be decomposed into components
• Collection – multiple literals or object types
• Structure – a fixed number of named elements, each of which could be a
literal or object type
• Attribute ranges
• Allowable values for an attribute
• enum – for enumerating the allowable values

95
Kinds of Collections
• Set – unordered collection without duplicates
• Bag – unordered collection that may contain duplicates
• List – ordered collection, all the same type
• Array – dynamically sized ordered collection, locatable by position
• Dictionary – unordered sequence of key-value pairs without
duplicates

96
Defining Structures
Structure = user-defined type with components
struct keyword
Example:
struct Address {
String street_address
String city;
String state;
String zip;
};

97
Defining Operations
• Return type
• Name
• Parentheses following the name
• Arguments within the
parentheses

98
Defining Relationships
• Only unary and binary relationships allowed
• Relationships are bi-directional
• implemented through use of inverse keyword
• ODL relationships are specified:
• relationship indicates that class is on many-side
• relationship set indicates that class is on one-side and other class (many)
instances unordered
• relationship list indicates that class is on one-side and other class (many)
instances ordered

99
Figure 15-1: UML class diagram for a university database

The following slides illustrate the

ODL implementation of this
UML diagram

100
Figure 15-2: ODL Schema for university database

101
Figure 15-2: ODL Schema for university database (cont.)

class keyword begins

the class
definition.Class
components enclosed
between { and }

102
Figure 15-2: ODL Schema for university database (cont.)

attribute has a data type and a name

specify allowable values

using enum

103
Figure 15-2: ODL Schema for university database (cont.)
extent = the set of all instances of the class

104
Figure 15-2: ODL Schema for university database (cont.)

Operation definition:
return type, name,
and argument list.
Arguments include
data types and names

105
Figure 15-2: ODL Schema for university database (cont.)

relationship sets indicate 1:N relationship to an

unordered collection of instances of the other class

inverse establishes the bidirectionality of the relationship

106
Figure 15-2: ODL Schema for university database (cont.)

relationship list indicates 1:N relationship to an

ordered collection of instances of the other class

107
Figure 15-2: ODL Schema for university database (cont.)

relationship indicates N:1 relationship to an

instance of the other class

108
In order to capture special features of
assignment, this should be converted into
two 1:N relationships

109
class Employee { Note:
(extent employees key indicates identifier
key emp_id) (candidate key)
………….
Note: attribute set indicates a
attribute set <string> skills_required;
multivalued attribute
};

110
 Note:
extends
denotes
subclassing
class HourlyEmployee
extends Employee{
( ………….

………….
}

111
Figure 15-5: UML class diagram showing student generalization

Note: abstract class denotes non-

instantiable (complete constraint)

abstract class Student{

( ………….

abstract float calc_tuition();

}

Note: abstract operation denotes no

method (no implementation) of
calc_tuition at the Student level

112
 Creating Object Instances
• Specify a tag that will be the object identifier
• MBA699 course ();
• Initializing attributes:
• Cheryl student (name: “Cheryl Davis”, dateOfBirth:4/5/77);
• Initializing multivalued attributes:
• Dan employee (emp_id: 3678, name: “Dan Bellon”,
skills {“Database design”, “OO Modeling”});
• Establishing links for relationship
• Cheryl student (takes: {OOAD99F, Telecom99F, Java99F});

113
Querying Objects in the
OODB
• Object Query Language (OQL)
• ODMG standard language
• Similar to SQL-92
• Some differences:
• Joins use class’s relationship name:
• Select x.enrollment from courseofferings x, x.belongs_to y where y.crse_course = “MBA 664” and
x.section = 1;
• Using a set in a query
• Select emp_id, name from employees where “Database Design” in skills;

114
Object Query Language
• OQL is DMG’s query language
• OQL works closely with programming languages such as C++
• Embedded OQL statements return objects that are compatible with
the type system of the host language
• OQL’s syntax is similar to SQL with additional features for objects
The schema defines the types Person and Employee. These types
have the extents Persons and Employees respectively. One of
these persons is the chairman (and there is an entry-point
Chairman to that person). The type Person defines the name,
birth-date, and salary as attributes and the operation age. The
type Employee, a subtype of Person, defines the relationship
subordinates and the operation seniority.

select distinct x.age from Persons x where x.name =

"Pat“
This selects the set of ages of all persons named Pat,
returning a literal of type set<integer>.
 select distinct struct(a:x.age, s: x.sex) from Persons x where x.name = "Pat";
This does about the same, but for each person, it builds a structure containing
age and sex. It returns a literal of type set<struct>.

select distinct struct(name: x.name, hps: (select y from x.subordinates as y

where y.salary >100000)) from Employees x
For each employee x, to compute hps, we traverse the relationship subordinates
and select among this set the employees with a salary superior to $100,000. The
result of this query is therefore a literal of the type set<struct>, namely:
set<struct(name: string, hps: bag<Employee>)>
A collection of objects with identity, e.g., select x from Persons x where
x.name ="Pat" returns a collection of persons whose name is Pat.
An object with identity, e.g., element(select x from Persons x where
x.passport_number=1234567) returns the person whose passport number is
1234567.
A collection of literals, e.g., select x.passport_number from Persons x where
x.name="Pat" returns a collection of integers giving the passport numbers of
people named Pat.
A literal, e.g., Chairman.salary.
Group the employees by street and compute the average salary in each
street:
define salary_map as
select street, average_salary:avg(select e.salary from partition)
from Employees e
group by street: e.address.street
The result is of type Bag<struct(street: string, average_salary:float)>. The
group by operator splits the employees into partitions, according to the
criterion (the name of the street where this person lives). The select clause
computes, in each partition, the average of the salaries of the employees
belonging to the partition.
Simple OQL Queries
• Basic syntax: select…from…where…
SELECT d.name
FROM d in departments
WHERE d.college = ‘Engineering’;
• An entry point to the database is needed for each query
• An extent name (e.g., departments in the above example) may
serve as an entry point
Iterator Variables
• Iterator variables are defined whenever a collection is referenced in
an OQL query
• Iterator d in the previous example serves as an iterator and ranges
over each object in the collection
• Syntactical options for specifying an iterator:
• d in departments
• departments d
• departments as d