Download Object Oriented & Object Relational Databases

Object Oriented & Object Relational Databases
Ranga Raju Vatsavai
Teaching Mentor (Prof. Shekhar)
CSci 5708 : Architecture and Implementation of Database
Management Systems, Fall 2003
Week 15 (11/24, 11/26/03) Lecture Notes
Outline for today 11/24/03


Objectives
Introduction


OO Fundamentals


Need for OO/OR-DBMS
How (OO)DBMS incorporates OO ideas
Database Modeling/Querying
Conceptual

Conclusions
OODBMS
ORDBMS
ODL/UML
EER/PEER
Outline for next class 11/26/03


Objectives
ORDBMS Fundamentals





How ORDBMS incorporates OO ideas
Mapping Conceptual Model into
Logical Model
OQL vs. SQL-99
Comparison of OODBMS and
ORDBMS
Conclusions
Learning Objectives





Basic concepts of OO and OR models
Extensions at conceptual modeling
Mapping Conceptual Model into Logical Model
Exposure to additional features in SQL:1999
standard.
Ability to model and implement a broader class of
applications (spatial, multimedia, engineering,
biological, scientific, …)
Introduction


Why OODBMS?
Let us start with modeling this simple example in
a RDBMS

Assume that we are given the following diagram
1
6
2
5
4
0,0
8
7
3
Introduction – Motivating Example

Our objective is to store this graph in a RDBMS
and support queries on these simple geometries



What kind of relations we need?
Print names of rectangles which are squares
Find all objects which are inside the rectangle 7.
1
6
2
5
4
0,0
8
7
3
Introduction – Motivating Example

Relations

POINT(pname, x, y), EDGE(ename, aPoint),
RECTANGLE(rname, anEdge).
POINT
RECTANGLE
EDGE
r5
e1
e1
p1
r5
e2
e1
p2
r5
e3
e2
p2
r5
e4
e2
p3
e3
p3
e3
p4
e4
p4
e4
p1
p1
3
4
p2
3
10
p3
10
10
p4
10
4
1
6
2
5
4
0,0
8
7
3
Introduction – Motivating Example

Logical Flow
rname
Edge_length (eName, eLength)
Rectangle r
Edge_Pnt_List (eName, stPnt, endPnt)
Point p1
Point p2
Edge e1
E1.ename = e2.ename
E1.aPoint <> e2.aPoint
Edge e2
Introduction – Motivating Example
CREATE VIEW pnt_list (ename, stPnt, endPnt)
AS SELECT e.ename, e1.aPoint, e2.aPoint
FROM edge e1, edge e2
WHERE
e1.ename = e2.ename
AND e1.aPoint <> e2.aPoint;
CREATE VIEW edge_length (ename, elength)
AS SELECT e.ename, sqrt(sq(p1.x –p2.x) + sq(p1.y – p2.y)
FROM pnt_list e, point p1, point p2
WHERE
e.stPnt = p1.pname
AND e.endPnt = p2.pname;
Introduction – Motivating
Example
Discussion Question –
Print the square names
Introduction – Motivating
Example
Solution
SELECT
r.rname
FROM
rectangle r, edge_length e
WHERE
r.anEdge = e.ename
GROUP BY r.rname
HAVING max(e.elength) ~ MIN (e.elength);
Introduction

Though we can model and query these simple
geometric objects, its




Not clean
Complexity increases with complex objects (like irregular
polygons)
Even with these simple objects, how do you answer
queries like ‘find nearest objects to point 2’ or ‘find all
intersecting objects’
What is lacking


Support for complex data types
Support for predicates (e.g., area, intersect, length)
OODBMS-Fundamentals


Has its origin in OO programming languages
Object



State – current value
Behavior - what operations are permitted
Difference between PL Object and DB Object



PL – Objects exist only during program execution
(transient objects).
DB – Objects persist beyond program termination; stored
permanently on a secondary storage
DB – allows sharing of objects among multiple programs
and applications
OODBMS-Fundamentals

OID – unique system generated object identifier
for each object


Compare this with RDBMS primary key
Object structure


Arbitrarily complex in order to contain all necessary
information about the object
Compare this with RDBMS


(rectangle object) – information about complex object is
often scattered
The state of complex object may be constructed from
other objects using type constructors
OODBMS-Fundamentals

Type constructors




Basic – atom, tuple, and set
Others – list, bag, and array (collection/bulk types)
tuple – also called as a structured type
Formally an object can be thought of as a triple
(I,C,V)



I – OID
C – type constructor
V – object state (current value)
OODBMS-Fundamentals

Examples





o1
o2
o3
o4
o5
=
=
=
=
=
(i1,
(i2,
(i3,
(i4,
(i4,
atom, ‘Pen-Chung Yew’)
atom, ‘Minneapolis’)
atom, ‘Computer Science’)
set, {i1,i2,i3})
tuple, <DNAME:i3, DCHAIR:i1>)
OODBMS-Fundamentals

Type hierarchies and Inheritance


OODB permits definition of new types based on other
predefined types, leading to a type hierarchy
Example






TYPE_NAME: function, function, …, function
PERSON: firstName, lastName, dob, SSN
STUDENT: firstName, lastName, dob, SSN, status, GPA
FACULTY: firstName, lastName, dob, SSN, rank, salary
STUDENT subtype_of PERSON: major, GPA
FACULTY subtype_of PERSON: rank, salary
OODBMS-Fundamentals

Exercise: Consider the geometry objects defined
in our first example and defined class hierarchies
1
6
2
5
4
0,0
8
7
3
OODBMS-Fundamentals

example 

GEOMETRY_OBJECT: Shape, Area, ReferencePoint
RECTANGLE subtype-of GEOMETRY_OBJECT
(Shape=‘rectangle’): edge1, edge2, edge3, edge4
OODBMS-Fundamentals

Standards:


ODMG
Made up of several parts





Object Model
Object Definition Language (ODL)
Object Query Language (OQL)
Binding to OO programming languages (C++, Smalltalk,
Java)
OOBMS



O2
ObjectStore
Jasmine
Database Modeling




Enhance Entity Relationship (EER – Chap 4,
Elmasri/Navathe)
Pictogram Enhanced Entity Relationship (PEER –
Chapter 2, SD A Tour).
Unified Modeling Language (UML)
Object Definition Language
Database Modeling

Example


We use two examples (school-DB) and park-DB (from
SDB-A Tour).
Identify typical objects (and hierarchies) in school-DB


Identify relationships


Person, Student, Faculty, Department
1:1, 1:M, M:N, partial participation, …
Let us start with EER


Includes all the modeling concepts of ER
Additionally includes oo concepts of – subclass,
superclass, specialization and generalization, attribute
and relationship inheritance
Database Modeling - EER
SSN
Person
lastName
dob
status
firstName
d
Student
Faculty
N
major
N
worksin
1
code
1
Department
name
rank
Database Modeling - EER

Find a suitable entity and define a overlapping
type of relationship
Database Modeling - UML
Person
SSN
dob
firstName
lastName
Faculty
0..1
Department chair
rank
chairOf
Code
majorsIn 1
worksIn *
dept
Name
major
1
Student
status
*
{disjoint, mandatory}
Database Modeling - PEER
Exactly one
Many (0 or More)
Optional (0 or One)
1+
One or More
Numerically Specified
Aggregation
Inheritance
Derived Class
OGC-Geometry
Database Modeling - PEER

State Park (ER Model)
Volume
Name
supplies
Length
Name
Geometry
Elevation
1
1
Forest
1
Name
manages
M
Fire_Station
Name
Geometry
1
Geometry
Geometry
N
1
Belongs_to
NoOfLanes
Road
M
access
Geometry
within
M
Name
Crosses
River
M
N
Facility
Geometry
Part_of
M
N
Forest_Stand
Stand-id
captures
M
Fire_Image
Image-id
Image
Specie
Database Modeling - PEER

Pictogram : miniature version of
geographic object inserted inside of a box



Entity pictograms
Relationship pictograms
Advantages




Ease of use
Complete grammar
Translation rules
Pictogram inserted ER diagram to SQL3 level constructs
Database Modeling - PEER

Pictograms
<Pictogram>
<Shape>
*
// any possible shape
!
// user-defined shapes
<Shape>
<Basic Shape>
<Multi-Shape>
<Derived Shape>
<Alternate Shape>
Database Modeling - PEER
<Basic
Shape>
Point
Line
Polygon
Pictograms for Basic Shapes
<Cardinality>
0,1
1
1,n
0,n
n
n
0, n
Pictograms for Multi-Shapes
Database Modeling - PEER
<Derived Shape>
<Basic Shape>
<Basic Shape>
Pictograms for Derived
<Basic Shape> Shapes
<Basic Shape> <Derived Shape>
Pictograms for Alternate
Shapes
Database Modeling - PEER
Any Possible Shape
*
Raster
User Defined Shape
Raster Shape
!
Raster
TIN
Thesian
TIN
Thesian
Pictograms for Raster
Shapes
Part_of (Network)
Part_of (Partition)
Pictograms for
Relationships
Database Modeling - PEER

State Park (PEER)
Volume
Name
supplies
Length
Name
Crosses
River
M
N
NoOfLanes
Road
M
access
Name
Elevation
N
Facility
Belongs_to
1
1
Forest
1
Name
M
manages
Fire_Station
Name
1
Part_of
M
N
captures
M
Fire_Image
Image-id
Forest_Stand
Stand-id
Specie
Summary and Conclusions

Learning Objectives



RDBMS limitations


No support for complex data types and predicates
OO



Understand OO Concepts
Conceptual Modeling
Rich set of features – encapsulation, inheritance, ..
Helps manage complexity
Conceptual Modeling – Simple Extensions
 EER, UML, PEER
Next Week





ORDMBS (SQL-3) in depth
Mapping of Conceptual Model onto
ORDBMS (SQL-3 DDL constructs)
Examples using Postgresql/PostGIS
Comparison of OODBMS and ORDBMS
Conclusions
Additional Readings



http://www.cs.umn.edu/~vatsavai/oo-ordbms.ppt
Main – Database Management Systems by Raghu
Ramakrishnan (Chapter 24: Object Database
Systems).
Additional References (relevant chapters):


Fundamentals of Database Systems – Elmasri & Navathe
A First Course In Database Systems – Ullman & Widom.


http://www-users.cs.umn.edu/~shekhar/5705/
Spatial Database – A Tour (Chapter 2 and 3)