Why object oriented dbms
This presentation is the property of its rightful owner.
Sponsored Links
1 / 23

Why Object-Oriented DBMS? PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Why Object-Oriented DBMS?. Abstract data types (relational data model is too simple). Interface with host programming language Managing large number of objects: Encapsulation, reusability Semantic networks: the worls is actually a complex hierarchy. SQL Doesn’t Work in Scotland.

Download Presentation

Why Object-Oriented DBMS?

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Why object oriented dbms

Why Object-Oriented DBMS?

  • Abstract data types (relational data model is too simple).

  • Interface with host programming language

  • Managing large number of objects:

    • Encapsulation, reusability

  • Semantic networks: the worls is actually a complex hierarchy.

Sql doesn t work in scotland

SQL Doesn’t Work in Scotland

Select name

From Employee

Where name > “Mc” and name < “Md”

OrderBy name

Doesn’t work for the McAndish clan:

(they’re all the same!)




Comparison based on ASCII

Other countries are even more problematic.

Two approaches to oo

Two Approaches to OO

1. Object Query Language: part of ODMG (that also gave us


2. Adding object features to SQL (row types and ADT’s). Also

known as Object-relational systems.

The difference: How important is a relation to you?

How important is SQL to you?

Object definition language

Object Definition Language

  • Resembles C++ (and Smalltalk).

  • Basic design paradigm in ODL:

    • Model objects and their properties.

  • For abstraction purposes:

    • Group objects into classes.

  • What qualifies as a good class?

    • Objects should have common properties.

Odl class declarations

ODL Class Declarations

Interface <name> {

attributes: <type> <name>;

relationships <range type> <name>;

methods (in, out, inout, exceptions)


Example method

Example Method

Interface Movie {

(extent Movies)

attribute string title;

relationship Set <Star> stars

inverse Star::starredIn;

float lengthInHours raises(noLengthFound);

starNames (out Set <String>);

otherMovies (in Star, out Set<Movie>)

raises (noSuchStar);


Note: defining signature, not implementation. Overloading allowed.

Oql object query language

OQL: Object Query Language

SELECT can construct new objects, arbitrary structures

FROM tuple variables can range over any collection; may

have subqueries.

WHERE pretty much the same as in SQL

Types in oql

Types in OQL

Declaring types for objects

Basic types:

Atomic types (e.g., string, integer, …)

Enumeration types (Monday, Tuesday, Wednesday….)

Constructors: can be applied without limitations.

Set: (1, 5, 6)

Bag: (1, 1, 5, 6, 6 )

List: (1, 5, 6, 1, 6 )

Array: Integer[17]

Struct: (name: string, address: string)

struct( name: “John”, childrenAges: bag (1,1,2,2))

Path expressions

Path Expressions

Path expressions are needed in order to access components

of objects.


a.p is the value of the attribute a of p.


a.p is the object or collection of objects related to a by p.


a.p is the result of applying p to a (perhaps with a parameter).

Also possible to have longer expressions:


Select from where in oql

Select-From-Where in OQL

(simple) Example:

SELECT s.name

FROM Movies m, m.stars s

WHERE m.title = “Sleepless in Seattle”

Note: this looks a lot more procedural than SQL.

Complications in the from clause

Complications in the FROM Clause

SELECT a.phoneNumber

FROM Movies m,

(SELECT m.address

FROM m.stars

WHERE m.city=“Los Angeles”)

AS a

WHERE m.title = “Sleepless in Seattle”

The FROM clause can contain arbitrary subqueries that return


Complex output types

Complex Output Types

The SELECT clause can create complex structures:

SELECT Struct: (address: a, phoneNumber: a.phoneNumber)

FROM Movies m,

(SELECT m.address

FROM m.stars

WHERE m.city=“Los Angeles”)

AS a

WHERE m.title = “Sleepless in Seattle”

Other features of oql

Other Features of OQL

  • Ordering of the results

  • ORDER BY m.title, m.year.

  • Subqueries wherever a collection is appropriate.

  • Quantifier expressions:

    • FOR ALL x IN S : C(x)

    • EXISTS x IN S:C(x)

  • Aggregation, grouping and HAVING clauses.

  • Set operators: UNION, INTERSECT, EXCEPT (different if

  • operating on bags or sets).

  • Remove duplicates: SELECT DISTINCT.

Interface with host language

Interface with Host Language

OQL is much more tightly integrated with the host language.

OQL produces objects (of various types). One can simply assign

the objects as values to variables with the appropriate types.

No need for special interface.

ELEMENT: turns a bag of one element into the single element:


FROM Movies m

WHERE title=“sleepless in Seattle”);

Handling sets or bags

Handling Sets or Bags

First: turn them into lists (using ORDER BY).

Then: use host language operations to go through them.


movieList = select m

FROM Movies m

WHERE m.year > 1990

ORDER BY m.title, m.year;

numberOfMovies = COUNT (movieList);

for (I=0; I < numberOfMovies; I++) {

movie = movieList[I]; do something with it.


Another example

Another Example

Schema: one relation Tour (S, E, C )

meaning: company C offers a tour from city S to city E.

Query: find for every city, the companies giving tours of itself.


C : (SELECT y.C from y in Tour

WHERE x.E=y.S and x.S=y.E) ]

FROM x in Tour

Final example

Final Example



FROM y in Tour, y’ in Tour

WHERE x.S=y.S and x.E=y.E

and x.E=y’.S and x.S=y’.E

and y.C = y’.C)]

from x in Tour.

Find companies offering tours from city S to some destination

E and back to S.

Row types in sql 3

Row Types in SQL-3

Row types define types for tuples, and they can be nested.


street CHAR(50),

city CHAR(25),

zipcode CHAR(10)



name CHAR(30),

address AddressType,

phone phoneNumberType


Relations as row types

Relations as Row Types


Recall: row types can be nested!

Accessing components of a row type: (double dots)

SELECT Person.name, Person.address..city

FROM Person

WHERE Person.address..street LIKE ‘%Mountain%’



We can define attributes of a row type to reference objects of other

row types:


name char(30),

address addressType,

president REF(PersonType)


Following references:

SELECT president->name

FROM Company

WHERE president->address..city=“Seattle”

Abstract data types in sql3

Abstract Data Types in SQL3

  • Row types provide a lot of the functionality of objects:

    • allow us to modify objects (unlike OQL), but

    • do not provide encapsulation.

      • We can modify objects arbitrarily using SQL3 commands.

      • In OQL: we can query, but not modify only via methods.

  • Abstract data types: are used as components of tuples.

  • CREATE TYPE <type name> (

  • list of attributes and their types

  • optional declaration of the comparison functions: =, <

  • declaration of methods for the type

  • );

Address adt

Address ADT


street CHAR(50),

city CHAR(20),

EQUALS addrEq,


FUNCTION fullAddr (a: AddressADT) RETURNS CHAR(100);

:z CHAR(10);


:z = findZip(:a.street, :a.city);






Encapsulation is obtained by making methods public/private

Differences between oodb approaches

Differences Between OODB Approaches

  • Programming environment: much more closely coupled in

  • OQL/ODL than in SQL3.

  • Changes to objects are done via the programming language in

  • OQL, and via SQL statements in SQL3.

  • Role of relations: still prominent in SQL 3

    • Row types are really tuples, ADT’s describe attributes.

    • In OQL: sets, bags and structures are fundamental.

  • Encapsulation: exists in OQL; not really supported by row types

  • in SQL3, but are supported by ADT’s.

  • Login