why object-oriented dbms?

23
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.

Upload: mairi

Post on 12-Jan-2016

22 views

Category:

Documents


0 download

DESCRIPTION

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. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: 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.

Page 2: Why Object-Oriented DBMS?

SQL Doesn’t Work in Scotland

Select nameFrom EmployeeWhere name > “Mc” and name < “Md”OrderBy name

Doesn’t work for the McAndish clan: (they’re all the same!)

McAndish MacAndish M’Andish

Comparison based on ASCII

Other countries are even more problematic.

Page 3: Why Object-Oriented DBMS?

Two Approaches to OO

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

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?

Page 4: Why Object-Oriented DBMS?

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.

Page 5: Why Object-Oriented DBMS?

ODL Class Declarations

Interface <name> {

attributes: <type> <name>;

relationships <range type> <name>;

methods (in, out, inout, exceptions)

}

Page 6: Why Object-Oriented DBMS?

Example MethodInterface 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.

Page 7: Why Object-Oriented DBMS?

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

Page 8: Why Object-Oriented DBMS?

Types in OQL

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))

Declaring types for objects

Page 9: Why Object-Oriented DBMS?

Path ExpressionsPath expressions are needed in order to access componentsof objects.

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

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

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

Also possible to have longer expressions: a.father.wife.child.father.wife….

Page 10: Why Object-Oriented DBMS?

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.

Page 11: Why Object-Oriented DBMS?

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 returncollections.

Page 12: Why Object-Oriented DBMS?

Complex Output TypesThe 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”

Page 13: Why Object-Oriented DBMS?

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.

Page 14: Why Object-Oriented DBMS?

Interface with Host Language OQL is much more tightly integrated with the host language.

OQL produces objects (of various types). One can simply assignthe 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:

var1 = ELEMENT (SELECT m FROM Movies m WHERE title=“sleepless in Seattle”);

Page 15: Why Object-Oriented DBMS?

Handling Sets or BagsFirst: turn them into lists (using ORDER BY).Then: use host language operations to go through them.

Example:

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.}

Page 16: Why Object-Oriented DBMS?

Another ExampleSchema: 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.

SELECT [S: x.S C : (SELECT y.C from y in Tour WHERE x.E=y.S and x.S=y.E) ]

FROM x in Tour

Page 17: Why Object-Oriented DBMS?

Final ExampleSELECT [S:x.S, C: (SELECT y.C 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 destinationE and back to S.

Page 18: Why Object-Oriented DBMS?

Row Types in SQL-3

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

CREATE ROW TYPE AddressType{ street CHAR(50), city CHAR(25), zipcode CHAR(10) }

CREATE ROW TYPE PersonType{ name CHAR(30), address AddressType, phone phoneNumberType}

Page 19: Why Object-Oriented DBMS?

Relations as Row TypesCREATE TABLE Person OF TYPE PersonType;

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%’

Page 20: Why Object-Oriented DBMS?

ReferencesWe can define attributes of a row type to reference objects of otherrow types:

CREATE ROW TYPE Company( name char(30), address addressType, president REF(PersonType));Following references:

SELECT president->name FROM Company WHERE president->address..city=“Seattle”

Page 21: Why Object-Oriented DBMS?

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 );

Page 22: Why Object-Oriented DBMS?

Address ADTCREATE TYPE AddressADT ( street CHAR(50), city CHAR(20), EQUALS addrEq, LESS THAN addrLT

FUNCTION fullAddr (a: AddressADT) RETURNS CHAR(100); :z CHAR(10); BEGIN :z = findZip(:a.street, :a.city); RETURN (….) END;DECLARE EXTERNAL findZip CHAR(50) CHAR(20) RETURNS CHAR(10) LANGUAGE C; );Encapsulation is obtained by making methods public/private

Page 23: Why Object-Oriented DBMS?

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.