Object-Relational SQL
CIS 4301
Lecture Notes
4/20/2006
Outline


User-Defined Data Types
Operations on Object-Relational Data
© CIS 4301 - Spring 2006
2
Sample Problem

Dept of WR management in CA maintains database of
images

40,000 digitized images, need to classify images electronically
create table slides (
id
int,
date
date,
caption
varchar(255),
picture
photo_CD_image);

create table landmarks (
name
varchar(50),
location point);
Query: Find all sunset pictures taken within 20 miles of
Sacramento
SELECT id
FROM slides P, landmarks L, landmarks S
WHERE sunset (P.picture) and contains (P.caption, L.name) and
L.location || S.location and S.name = ‘Sacramento’;
© CIS 4301 - Spring 2006
3
Need for Complex Data Types

Traditional database applications in data processing
had conceptually simple data types


Relatively few data types, first normal form holds
Complex data types have grown more important in
recent years

E.g. Addresses can be viewed as a





Single string, or
Separate attributes for each part, or
Composite attributes (which are not in first normal form)
E.g. it is often convenient to store multivalued attributes asis, without creating a separate relation to store the values in
first normal form
Applications


computer-aided design, computer-aided software
engineering
multimedia and image databases, and document/hypertext
databases
© CIS 4301 - Spring 2006
4
Object-Relational Systems



Need to allow DBMS’s to deal with
specialized types – maps, signals,
images, etc. – with their own
specialized methods
Need to support specialized methods
even on conventional relational data
Need to support structure more
complex than “flat files”
© CIS 4301 - Spring 2006
5
Object-Relational Systems

Object-oriented models support interesting
data types



Failed because they did not offer efficiencies of
well-accepted RDBMS’s
Relational model supports very high-level
queries
Object-relational systems are an attempt to
get the best of both worlds

Capture many of the advantages of OO yet retain
the relation as fundamental abstraction
© CIS 4301 - Spring 2006
6
SQL-99 and Oracle Features


SQL-99 includes many of the objectrelational features to be described
However, different DBMS’s use different
approaches (read manual before using)

We will use a mixture of features from
Oracle and SQL-99
© CIS 4301 - Spring 2006
7
User-Defined Types


Classes of ODL are morphed into Userdefined data types (UDTs) in SQL
UDT’s play a dual role:
1. They can be the types of relations; i.e., the
type of their tuple

Sometimes called a row type.
2. They can be the type of an attribute in a
relation
© CIS 4301 - Spring 2006
8
Defining UDT’s – Example in Oracle
Syntax
CREATE TYPE StudentType AS OBJECT (
name CHAR(20) UNIQUE,
addr CHAR(20),
age INTEGER
);
/
CREATE TYPE CampusType AS OBJECT (
name CHAR(20) UNIQUE,
location CHAR(20),
enrollment INTEGER
);
/
© CIS 4301 - Spring 2006
9
Notes


In Oracle, type definitions must be
followed by a slash (/) in order to get
them to compile.
The SQL standard is similar, but
“OBJECT” is not used after “AS”
© CIS 4301 - Spring 2006
10
References

If T is a type, then REF (T) is the type of
a reference to T, that is, a pointer to an
object of type T


a.k.a. object ID in OO speak
However, unlike object IDs, REF is visible
although it is usually gibberish
© CIS 4301 - Spring 2006
11
Example
CREATE TYPE ApplicationType AS OBJECT (
applicant REF(StudentType),
applied_at REF(CampusType),
received DATE
);
/

Sample ApplicationType object:
(&1, &2, 10-10-2001)
&1: (“John", “LA”, 18)
&2: (“USC", “LA”, 33000)
© CIS 4301 - Spring 2006
12
UDT’s as Row Types
A table may be defined to have a schema
that is a row type, rather than by listing
its elements
 Syntax:
CREATE TABLE <table-name> OF
<type-name>;

© CIS 4301 - Spring 2006
13
Example: Creating a Relation
CREATE TABLE Student OF StudentType;
CREATE TABLE Campus OF CampusType;
CREATE TABLE Application OF
ApplicationType;
© CIS 4301 - Spring 2006
14
Values of Relations with a Row
Type

Technically, a relation like Student, declared
to have a row type StudentType, is not a
set of triples

Unary relation whose tuples are objects with
three components: name, address, age
© CIS 4301 - Spring 2006
15
Values of User-Defined Types –
Oracle Approach


Each UDT has a type constructor of the
same name.
Values of that type are the values of its
fields wrapped in the constructor.
SELECT * FROM Student;
produces values such as
StudentType(“John”, “LA”, 18)
© CIS 4301 - Spring 2006
16
Accessing Fields of an Object
– Oracle Approach
The dot operator works as expected
 Thus, if we want the name and address without
the constructor:
SELECT S.name, S.addr
FROM Student S;


The alias S is not technically necessary, but
there are other places where we must use an
alias in order to access objects, and it is a good
habit to use an alias always
SQL standard: Same idea, but the attribute is
treated as a generator method, with
parentheses, e.g., S.name()
© CIS 4301 - Spring 2006
17
Accessing Fields of an Object
– SQL-99 Approach

Same query in SQL-99 is:
SELECT S.name(), S.addr()
FROM Student S;
© CIS 4301 - Spring 2006
18
Inserting Values – Oracle
Approach

We can use the standard INSERT in
Oracle, but we must wrap the inserted
object in its type-constructor

Relation with row type is really unary!!
INSERT INTO Student VALUES(
StudentType(“Andy”, “SF”, 19)
);

SQL standard involves generator and
mutator methods; see text
© CIS 4301 - Spring 2006
19
UDT as Column Type


Remember, UDT can be type of an
attribute
In either another UDT definition or
another create table statement, use the
name of the UDT as the type of the
attribute
© CIS 4301 - Spring 2006
20
Example – Oracle Syntax

Let’s create an address type for use with Student and Applications
CREATE TYPE AddrType AS OBJECT (
street CHAR(30),
city CHAR(20),
zip INT
);

Then we can say:
CREATE TABLE Student (
name CHAR(20) UNIQUE,
addr AddrType,
age INTEGER
);
© CIS 4301 - Spring 2006
21
Need to Use Aliases

If you access an attribute whose type is an
object type, you must use an alias for the
relation E.g.,
SELECT addr.city
FROM Student;
will not work in Oracle; neither will:
SELECT Student.addr.city
FROM Student;
You have to say:
SELECT S.addr.city
FROM Student S;
© CIS 4301 - Spring 2006
22
References Revisited
Remember, UDT’s can have references.
 If T is a UDT, then REF(T) is the type of a
reference to a T object.
 Unlike OO systems, refs are values that
can be seen by queries.
© CIS 4301 - Spring 2006
23
Dereferencing in SQL
A  B = the B attribute of the object
referred to by reference A
Find the Universities that Joe applied to
SELECT applied_at -> name,
applied_at -> location
FROM Application
WHERE applicant -> name = “Joe”;
© CIS 4301 - Spring 2006
24
Dereferencing in Oracle


Dereferencing automatic, using dot
operator
Same query in Oracle syntax:
SELECT App.applied_at -> name,
App.applied_at -> location
FROM Application App
WHERE App.applicant -> name =
“Joe”;
© CIS 4301 - Spring 2006
25
Oracle’s DEREF Operator

If we wanted the entire CampusType object,
we might try to write
SELECT App.applied_at
FROM Application App
WHERE ss.applicant.name = “Joe”;


Legal, but App.applied_at is a reference,
and we’d get a gibberish value
To see the whole campus object, use:
SELECT DREF(App.applied_at)
FROM Application App
WHERE ss.applicant.name = “Joe”;
© CIS 4301 - Spring 2006
26
Methods




Real reason object-relational isn’t just nested
structures in relations
We’ll follow Oracle syntax.
Declared in a CREATE TYPE statement, defined in
a CREATE TYPE BODY statement
Methods are functions or procedures; in Oracle
they are defined like any PL/SQL procedure or
function

But, there is a special tuple variable SELF that refers to
that object to which the method is applied
© CIS 4301 - Spring 2006
27
Example

Let’s add a method rank to the ApplicationType and thus to the
Application relation
CREATE TYPE ApplicationType AS OBJECT (
applicant REF(StudentType),
applied_at REF(CampusType),
received DATE
MEMBER FUNCTION rank(
SAT IN INTEGER) RETURN INTEGER,
PRAGMA RESTRICT_REFERENCES(rank, WNDS)
);
CREATE TYPE BODY ApplicationType AS
MEMBER FUNCTION rank(SAT INTEGER)
RETURN INTEGER IS
BEGIN
// body of function goes here;
END;
END;
/
CREATE TABLE Application OF ApplicationType;
© CIS 4301 - Spring 2006
28
Some Points to Remember

The pragma is needed to allow rank to be used in
queries


In the declaration, function/procedure arguments
need a mode, IN, OUT, or IN OUT, just like PL/SQL
procedures


But the mode does not appear in the definition
Many methods will take no arguments (relying on the
built-in “self”)


WNDS = “write no database state”
In that case, do not use parentheses after the function name
The body can have any number of function
declarations, separated by semicolons
© CIS 4301 - Spring 2006
29
Example of Method Use

Follow a designator for the object to
which you want to apply the method by a
dot, the name of the method, and
argument(s)
SELECT App.applicant.name,
App.rank(789)
FROM Application App
WHERE App.applicant.name = “Joe”;
© CIS 4301 - Spring 2006
30
Built-In Comparison Functions
(SQL)


We can define for each UDT two functions EQUAL and
LESSTHAN
Allow values of this UDT to participate in WHERE clauses
involving =, <=, etc. and in ORDER-BY sorting
Order Methods in Oracle



We can declare one method for a type to be an ORDER
method
Definition of this method must return -1, 0, 1, if “self” is
less than, equal to, or greater than the argument object
Also used in comparisons for WHERE and ORDER BY
© CIS 4301 - Spring 2006
31
Example
Order StudentType objects by name:
CREATE TYPE StudentType AS OBJECT (
name CHAR(20) UNIQUE,
addr CHAR(20),
age INTEGER,
ORDER MEMBER FUNCTION before(
student2 IN StudentType) RETURN INT,
PRAGMA RESTRICT_REFERENCES(before,
WNDS,RNDS,WNPS,RNPS)
);
/
© CIS 4301 - Spring 2006
32
Body
CREATE TYPE BODY StudentType AS
ORDER MEMBER FUNCTION
before(student2 StudentType)
RETURN INT IS
BEGIN
IF SELF.name < student2.name
THEN RETURN -1;
ELSIF SELF.name = student2.name
THEN RETURN 0;
ELSE RETURN 1;
END IF;
END;
END;

The extra codes in the pragma guarantee no reading or writing of the
database state or the “package state”
© CIS 4301 - Spring 2006
33
Not Covered





Nested relations
Collections
Other type constructors
Inheritance
etc.
© CIS 4301 - Spring 2006
34