Object Oriented

Published on June 2017 | Categories: Documents | Downloads: 38 | Comments: 0 | Views: 311
of 21
Download PDF   Embed   Report

Comments

Content

Why Object-Oriented DBMS?
• Abstract data types
• Interface with host programming language (the impedance mismatch).
• Object identity:
• (peter, 40, {(john, 15, {})})
• (susan, 41, {(john, 15, {})})

– Same son? Maybe, maybe not.

• Managing large number of objects:
– Encapsulation, reusability, modularity, protection, less distinction between
program and data, type extensibility

• Semantic networks: the world is actually a complex hierarchy
(types versus classes).

SQL Doesn’t Work in Scotland
Select name
From Employee
Where name > “Mc” and name < “Md”
OrderBy name
Comparison based on ASCII

Doesn’t work for the McAndish clan:
(they’re all the same!)
McAndish
MacAndish
M’Andish
Other countries are even more problematic.

Programs with SQL
Host language + Embedded SQL
Preprocessor
Preprocessor
Host Language + function
calls
Host
Host language
language compiler
compiler
Host language program

Cursors
EXEC SQL DECLARE cursorName CURSOR FOR
SELECT …. FROM …. WHERE …. ;
EXEC SQL OPEN cursorName;
while (true) {
EXEC SQL FETCH FROM cursorName INTO :variables;
if (NO_MORE_TUPLES) break;
/* do something with values */
}
EXEC SQL CLOSE cursorName;

Two Approaches to OO
1. Build object-oriented database systems:
• ODMG standard: --> Object Query Language.
• Products are mainly object storage systems.
• Only O2 supports OQL (and is not doing that well).
2. Object-relational systems:
• Add OO features to SQL (in SQL3)
• Row types and abstract data types.
• Various subsets are supported my most relational vendors.
The difference:
• How important is a relation to you?
• How important is SQL to you?

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
Interface <name> {
attributes: <type> <name>;
relationships <range type> <name>;
methods (in, out, exceptions)
}

Example Interface
Interface Movie {
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.

Type System
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 )
Collection types
Array: Integer[17]
Struct: (name: string, address: string)
struct( name: “John”, childrenAges: bag (1,1,2,2))

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

Path Expressions
Path expressions are needed in order to access components
of 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….

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

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”

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:
var1 = ELEMENT (SELECT m
FROM Movies m
WHERE title=“sleepless in Seattle”);

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
}

Relations as Row Types
CREATE 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%’

References
We can define attributes of a row type to reference objects of other
row 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”

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

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.

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close