Object Oriented Database Management

Motivation of ODBMSs

Application
data structures
Copy and
Transparent
translation
Relational ODBMS
representation data transfer

RDBMS

• Complex objects in emerging DBMS applications cannot be effectively

represented as records in relational model.
• Representing information in RDBMSs requires complex and inefficient
conversion into and from the relational model to the application
programming language
• ODBMSs provide a direct representation of objects to DBMSs overcoming
the impedance mismatch problem
 Embedded SQL

• Access to database from a general purpose programming language required since:

– Not all queries can be expressed in SQL --e.g., recursive queries cannot be written
in SQL.
– Non declarative actions -- e.g., printing reports cannot be done from SQL.
• General purpose language in which SQL is embedded called host language.
• SQL structures permitted in host language called embedded SQL.

C compiler
SQL library calls + C
SQL+ C
pre-
compiler
.o file
loader
SQL library
object
code

Embedded SQL Compilation

 Embedded SQL

• SQL commands embedded in the host programming language

• Data exchanged between host language and DBMS using cursors
• SQL query passed from host language to DBMS which computes
the answer set
• A cursor can be viewed as a pointer into the answer set
• DBMS returns the cursor to the programming language
• Programming language can use the cursor to get a record at a
time access to materialized answer.
 Example of Embedded SQL
namespace WindowsFormsApplication25
{
public partial class Form1 : Form
{
public Form1()
{ InitializeComponent(); }

private void button1_Click(object sender, EventArgs e)

{
SqlConnection conn = new SqlConnection("Data Source=PCNAME;Initial Catalog=DB;Integrated
Security=true");
SqlCommand cmd = new SqlCommand("delete from teachers where tid = '" + Convert.ToInt16(textBox1.Text) +
"'", conn);
conn.Open();

int del;
try { del = cmd.ExecuteNonQuery();
MessageBox.Show(del+" Records Deleted Successfully!!!");
} catch { MessageBox.Show("Cannot Delete Any record!!!"); }
} } }

/* SQL embedded in C# to delete record of teacher where “tid” is equal to the user input*/
 Object Oriented Database Management

• Object Oriented databases have evolved along two different paths:

• Persistent Object Oriented Programming Languages: (pure ODBMSs)
– Start with an OO language (e.g., C++, Java, SMALLTALK) which
has a rich type system
– Add persistence to the objects in programming language where
persistent objects stored in databases
• Object Relational Database Management Systems (SQL3 Systems)
– Extend relational DBMSs with the rich type system and user-defined
functions.
– Provide a convenient path for users of relational DBMSs to migrate to
OO technology
– All major vendors (e.g., Informix, Oracle) will/are supporting
features of SQL3.
 Object Database Management Group (ODMG)

• Special interest group to develop standards that allow ODBMS

customers to write portable applications
• Standards include:
– Object Model
– Object Specification Languages
• Object Definition Language (ODL) for schema definition
• Object Interchange Format (OIF) to exchange objects between databases
– Object Query Language
• declarative language to query and update database objects
– Language Bindings (C++, Java, Smalltalk)
• Object manipulation language
• Mechanisms to invoke OQL from language
• Procedures for operation on databases and transactions
 Object Model

• Object:
– observable entity in the world being modeled
– similar to concept to entity in the E/R model
• An object consists of:
– attributes: properties built in from primitive types
– relationships: properties whose type is a reference to some other object
or a collection of references
– methods: functions that may be applied to the object.
 Class

• Similar objects with the same set of properties and describing

similar real-world concepts are collected into a class.
• Class definition:

interface Employee { Interface Projects{

attribute string name;
attribute string name;
attribute integer projid;
attribute integer salary;
relationship Employee team
attribute date date-of-birth;
inverse Emplolyee works-for;
attribute integer empid; int number-of-employees();
relationship Projects works-for }
inverse Projects::team;
age-type age();
}
 Class Extents

• For each ODL class, an extent may be declared.

• Extent is the current set of objects belonging to the class.
– Similar notion to the relation in the relational model.
– Queries in OQL refer to the extent of a class and not the class
directly.

interface Employee (extent Emp-set)

{ attribute string name;
attribute integer salary;
attribute date date-of-birth;
attribute integer empid;
relationship Projects works-for
inverse Projects::team;
age-type age(); }
 Subclasses and Inheritance

• A class can be declared to be a subclass of another class.

• Subclasses inherit all the properties
– attributes
– relationships
– methods
from the superclass.

Interface Married-Employee: Employees {

string spouse-name;
}

• Substitutability: any method of superclass can be invoked over

objects of any subclass (code reuse)
 Class Hierarchy

person

employee student

student grad undergrad

staff faculty assistant

RA TA
 Multiple Inheritance

• A class may have more than one superclass.

• A class inherits properties from each of its superclasses.
• There is a potential of ambiguity -- variable with same name
inherited from two superclasses:
– flag and error
– rename variable
– choose one
 Object Identity

• Each object has an identity which it maintains even if some or all

of its attributes change.
• Object identity is a stronger notion of identity than in relational
DBMSs.
• Identity in relational DBMSs is value based (primary key).
• Identity in ODBMSs built into data model
– no user specified identifier is required
• OID is a similar notion as pointer in programming language
• Object identifier (OID) can be stored as attribute in object to refer
to another object.
• References to other objects via their OIDs can result in a
containment hierarchy
• Note: containment hierarchy different from class hierarchy
 Containment Hierarchy

bicycle

wheel brake gear frame

tire rim spoke lever pad

Links in containment hierarchy should be read as is-part-of instead of is-a

 Persistence

• Objects created may have different lifetimes:

– transient: allocated memory managed by the programming language
run-time system.
• E.g., local variables in procedures have a lifetime of a procedure execution
• global variables have a lifetime of a program execution
– persistent: allocated memory and stored managed by ODBMS runtime
system.
• Classes are declared to be persistence-capable or transient.
• Different languages have different mechanisms to make objects
persistent:
– creation time: Object declared persistent at creation time (e.g., in C++
binding) (class must be persistent-capable)
– persistence by reachability: object is persistent if it can be reached from
a persistent object (e.g., in Java binding) (class must be persistent-
capable).
 Persistent Object-Oriented Programming Languages

• Persistent objects are stored in the database and accessed from the
programming language.
• Classes declared in ODL mapped to the programming language type
system (ODL binding).

• Single programming language for applications as well as data

management.
– Avoid having to translate data to and from application programming
language and DBMS
• efficient implementation
• less code
– Programmer does not need to write explicit code to fetch data to and from
database
• persistent objects to programmer looks exactly the same as transient objects.
• System automatically brings the objects to and from memory to storage device.
(pointer swizzling).
 Disadvantages of ODBMS Approach

• Low protection
– since persistent objects manipulated from applications directly, more
changes that errors in applications can violate data integrity.
• Non-declarative interface:
– difficult to optimize queries
– difficult to express queries
• But …..
– Most ODBMSs offer a declarative query language OQL to overcome the
problem.
– OQL is very similar to SQL and can be optimized effectively.
– OQL can be invoked from inside ODBMS programming language.
– Objects can be manipulated both within OQL and programming language
without explicitly transferring values between the two languages.
– OQL embedding maintains simplicity of ODBMS programming language
interface and yet provides declarative access.
 OQL Example

Interface Projects{
interface Employee {
attribute string name;
attribute string name; relationship setof(Employee) team
relationship inverse Emplolyee works-for;
setof(Projects) works-for int number-of-employees();
inverse Projects::team; }
}

Select number-of-employees()
From Employee e, e.works-for
where name = “sharad”

Find number of employees working on each project “sharad” works on

 Migration of RDBMSs towards OO Technologies

• SQL3 standard incorporates OO concepts in the relational model.

• A row in a table considered as an object
• SQL3 allows a type to be declared for tuples (similar to class in
ODBMSs)
• Relations are collection of tuples of a row type (similar to extent in
ODBMSs)
• Rows in a relation can refer to each other using a reference type
(similar to object identity in ODBMSs)
• A reference can be dereferenced to navigate among tables
• Attributes in a relation can belong to abstract data types
• Methods and functions (expressed in SQL as well as host
programming language) can be associated with abstract data
types
 SQL-3 Example

CREATE ROW TYPE Employee-type {

name CHAR(30)
works-for REF(Projects-type)
}
CREATE ROW TYPE Projects-type {
name CHAR(30)
team setof(REF(Employee-type))
}
CREATE TABLE Emp OF TYPE Employee-type
CREATE TABLE Project of TYPE Project-type

Select works-for --> name

From Emp Return name of the project
Where name = ‘sharad’ sharad works for
 OQL

CMSC-461
Database Management Systems
 OQL -- Motivation

• Relational languages suffer from impedance mismatch when we

try to connect them to conventional languages like C or C++.
– The data models of C and SQL are radically different, e.g. C does not
have relations, sets, or bags as primitive types; C is tuple-at-a-time,
SQL is relation-at-a-time.
 OQL -- Motivation (II)

• OQL is an attempt by the OO community to extend languages like

C++ with SQL-like, relation-at-a-time dictions.
• OQL is query language paired with schema-definition language
ODL.
 OQL Types

• Basic types: strings, ints, reals, etc., plus class names.

• Type constructors:
– Struct for structures.
– Collection types: set, bag, list, array.
• Like ODL, but no limit on the number of times we can apply a
type constructor.
• Set(Struct()) and Bag(Struct()) play special roles akin to relations.
 OQL Uses ODL as its Schema-Definition Portion

• For every class we can declare an extent = name for the current
set of objects of the class.
– Remember to refer to the extent, not the class name, in queries.
 Example

• interface Bar
(extent Bars)
{
attribute string name;
attribute string addr;
relationship Set<Sell> beersSold
inverse Sell::bar;
}
 Path Expressions

• Let x be an object of class C.

• If a is an attribute of C, then x.a = the value of a in the x object.
• If r is a relationship of C, then x.r = the value to which x is
connected by r.
– Could be an object or a collection of objects, depending on the type of
r.
• If m is a method of C , then x.m (...) is the result of applying m to x.
 Examples

• Let s be a variable whose type is Sell.

• s.price = the price in the object s.
• s.bar.addr = the address of the bar mentioned in s .
– Note: cascade of dots OK because s.bar is an object, not a collection.
 Example of Illegal Use of Dot

• b.beersSold.price, where b is a Bar object.

• Why illegal? Because b.beersSold is a set of objects, not a single
object.
 Subqueries

• Used mainly in FROM clauses and with quantifiers EXISTS and

FORALL.
 Example: Subquery in FROM

• Find the manufacturers of the beers served at Joe's.

SELECT b.manf
FROM (
SELECT s.beer
FROM Sells s
WHERE s.bar.name = "Joe's Bar"
)b
 Aggregation

• The five operators avg, min, max, sum, count apply to any
collection, as long as the operators make sense for the element
type.
 Example

• Find the average price of beer at Joe's.

• x = AVG(
SELECT s.price
FROM Sells s
WHERE s.bar.name = "Joe's Bar"
);
• Note coercion: result of SELECT is technically a bag of 1-field structs,
which is identified with the bag of the values of that field.
 Grouping

• Recall SQL grouping, for example:

SELECT bar, AVG(price)
FROM Sells
GROUP BY bar;
• Is the bar value the "name" of the group, or the common value for
the bar component of all tuples in the group?
SQL3 Objects
 Objects in SQL3

• OQL extends C++ with database concepts, while SQL3 extends

SQL with OO concepts.
 Objects in SQL3 (II)

• Ullman's personal opinion: the relation is so fundamental to data

manipulation that retaining it as the core, as SQL3 does, is
"right."
• Systems using the SQL3 philosophy are called object-relational.
 References

• Row types can have references.

• If T is a row type, 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.
 Example of Row Types

• CREATE ROW TYPE BarType (

name CHAR(20) UNIQUE,
addr CHAR(20)
);
• CREATE ROW TYPE BeerType (
name CHAR(20) UNIQUE,
manf CHAR(20)
);