OBJECT-DATABASE SYSTEMS 1 Loreto Bravo WEAKNESS of RDBMSS

OBJECT-DATABASE SYSTEMS 1 Loreto Bravo WEAKNESS OF RDBMSS

| Poor support for complex data: y New database applications need more & better support for complex data. | Poor representation of ‘real world’ entities y normalization generally leads to the creation of relations that do not corresponds to entities in the ‘real world’. | Semantic overloading: y No mechanism to distinguish between entities and relationships, y No mechanism to distinguish between different relationships. | Limited Operations y fixed set of operations such as set and tuple – oriented operations | Impedance mismatch 2 y difficulties associated to using RDBMS with an OO-language NEW DATABASE APPLICATIONS NEEDS

| New applications need to handle complex data: y Computer-aided design (CAD): data relating to mechanical and electrical design (buildings, IC circuits, etc.) y Computer-aided software engineering (CASE): stages of the software development lifecycle planning. y Geographic Databases y Multimedia Databases | Richer data types needed: images, audio, video, geographical data, text | Need for inheritance | Need for query languages that can handle complex data types 3 DEVELOPMENT OF OBJECT DATABASE SYSTEMS

| Two paths: y Object-Oriented Database Systems:

| Alternative to relational databases

| For domains in which objects play a central role

| Very influenced by object-oriented programming languages

| Adding DBMS functionality to an object-oriented programming language environment

| Standards:

| ODL: Object Definition Language

| OQL: Object Query Language y Object-Relational Database Systems

| Extension of RDMS to handle objects

| SQL3 extends SQL to support object-relational model of data

4 OBJECT-ORIENTED DATABASE SYSTEMS (OODBMS) 5 Loreto Bravo OBJECT ORIENTED CONCEPTS

| User defined data-types: y Rich collection of types y Classes, which are types that may include methods, which are procedures that are applicable to objects belonging to the class. | Object Identity: each object has a unique identifier, independent of its value y Two objects with the same attributes are still distinguishable | Inheritance: there is a class hierarchy and classes can inherit properties of classes above it. | Encapsulation: structure of an object is not visible to the external world y Only operations defined by methods can be applied over objects

| All these concepts apply also for OODBMS 6 OODBMS

| Extend the concepts of OO programming languages (C++, Java, etc) to include persistence y In OO-programas objects only exist at execution time y In OODBMS this is modified so that objects can be preserved indefinitely, unless changed by the user. | Standards: y Object-oriented data model: ODL (object definition language) y Object-oriented query language: OQL (object query language)

7 OBJECT DEFINITION LANGUAGE (ODL)

| Basic design paradigm in ODL: y Model objects and their properties. | Class=Interface+Implementation y ODL defines the interface

Interface { attributes: ; relationships ; methods (in, out, inout, exceptions)}

y The implementation will depend on the language (C++, Smalltalk or Java) used in the OODBMS

8 TYPES IN ODL

| Basic types: y Atomic types (e.g., string, integer, …) y Enumeration types (Monday, Tuesday, Wednesday ….) | Constructors: can be applied without limitations. y Set: (1, 5, 6) y Bag: (1, 1, 5, 6, 6 ) y List: (1, 5, 6, 1, 6 ) y Array: Integer[17] | Examples: y Struct: (string name, string address) y Struct: (name: “John”, childrenAges: bag (1,1,2,2))

9 EXAMPLE WITH METHOD

Interface Movie { (extent Movies key title) attribute string title; relationship Set stars inverse Star::starredIn;

float lengthInHours raises(noLengthFound);

starNames (out Set );

otherMovies (in Star, out Set) raises (noSuchStar);

} 10 BANKING EXAMPLE 1

Ss# name amount loandid address type customer borrower loans

Belongs-to

Customer-of branch

branchid location

Keys: ss#, loanid, branchid

Cardinality constraint: each loan belongs to a single branch 11 BANKING EXAMPLE (II)

interface Customer { attribute string name; attribute integer ss#; attribute Struct Addr {string street, string city, int zip} address; relationship Set borrowed inverse Loans::borrower; relationship Set has-account-at inverse Branch::patrons; key(ss#) } | Structured types have names and bracketed lists of field- type pairs. | Relationships have inverses. | An element from another class is indicated by < class > or :: 12 | Form a set type with Set. LOANS EXAMPLE (III) interface loans { attribute real amount; attribute int loanid; attribute Enum loanType {house, car, general} type; relationship Branch belongs-to inverse Branch::loans-granted; relationship Set borrower inverse Customer::borrowed; key(loanid) }

| Enumerated types have names and bracketed lists of values.

13 BANK EXAMPLE (IV)

interface Branch { attribute integer branchid; attribute Struct Customer::Addr location; relationship Set loans-granted inverse Loans::belongs-to; relationship Set patrons inverse Customer::has-account-at; key(branchid); } | Note reuse of Addr type defined in Customer.

14 TYPES OF RELATIONSHIPS

| The Banking example shows many-many and many-to- one relationships | All ODL relationships are binary. y Many-many relationships have Set<…> for the type of the relationship and its inverse. y Many-one relationships have Set<…> in the relationship of the “one” and just the class for the relationship of the “many.” y One-one relationships have classes as the type in both directions.

15 is-a relationship INHERITANCE interface Instructor:Person ( extent Instructors ) { attribute long salary; attribute string rank; attribute Degrees degrees; relationship Department dept inverse Department::instructors; relationship set teaches inverse Course::taught_by; long works_for (); short courses ( in string dept_name ); };

16 ANOTHER EXAMPLE (FROM ULLMAN CS145)

Names for the names of the structure and class Bar { attributes enumeration attribute string name; attribute Struct Addr {string street, string city, int zip} address; attribute Enum Lic { FULL, BEER, NONE } license; relationship Set serves inverse Beer::servedAt; } The :: operator connects The type of relationship serves a name on the right to the is a set of Beer objects. context containing that name, on the left.

17 ANOTHER MULTIPLICITY EXAMPLE

class Beer { attribute string name; attribute string manf; relationship Set servedAt inverse Bar::serves; } husband and wife are one-one and inverses class Drinker { of each other. attribute … ; relationship Drinker husband inverse wife; relationship Drinker wife inverse husband; relationship Set buddies inverse buddies; } buddies is many-many and its own inverse. Note no :: needed 18 if the inverse is in the same class. OQL: OBJECT QUERY LANGUAGE

| OQL is the object-oriented query standard. | It uses ODL as its schema definition language. | Types in OQL are like ODL’s. | Set(Struct) and Bag(Struct) play the role of relations.

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

19 PATH EXPRESSIONS

| Path expressions are needed in order to access components of objects. y Attributes:

| a.p is the value of the attribute p of a y Relationships:

| a.p is the object or collection of objects related to a by p. y Methods:

| a.p is the result of applying p to a (perhaps with a parameter). | Also possible to have longer expressions: y a.father.wife.child.father.wife….

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

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

22 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”

23 OTHER FEATURES OF OQL

| Ordering of the results y ORDER BY m.title, m.year. | Quantifier expressions: y FOR ALL x IN S : C(x) y 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.

24 INTERFACE WITH HOST LANGUAGE

| OQL is much more tightly integrated with the host language. | OQL produces objects (of various types). y One can simply assign the objects as values to variables with the appropriate types. y No need for special interface. | ELEMENT: turns a bag of one element into the single element: y var1 = ELEMENT (SELECT m FROM Movies m WHERE title=“sleepless in Seattle”);

25 HANDLING SETS OR BAGS

| First: 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]; … } 26 EXAMPLE

| Schema one relation Tour (S, E, C ) meaning: y 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

27 EXAMPLE

SELECT [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 destination E and back to S.

28 ADVANTAGES / DISADVANTAGES OF OODB Advantages Disadvantages

•Class inheritance •Handling of relationships ¾Cumbersome •Encapsulation of ¾Data duplicated attributes/methods ¾Consistency not enforced •Extensible/flexible definition Table based representation is often more of complex data types and ¾Natural methods(support for complex ¾Intuitive objects) ¾Efficient •Much greater power given to Integrity/consistency poorly enforced the programmer to add or ¾More restrictive relational mode semantics change databases semantics. makes integrity correctness enforcement easier.

29 PRODUCTOS ODBMS

| Extend the relational model to include many of the common object-oriented concepts | Part of the SQL-99 (or SQL:1999, or SQL3) y This standard forms the basis for object-relational DBMS's that are now available from essentially all the major vendors y However, vendors differ considerably in the details of how the concepts are implemented and made available to users

32 ROW TYPES IN SQL-3 Row types define types for tuples, and they can be nested.

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

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

) 33 RELATIONS AS ROW TYPES

CREATE TABLE Person OF TYPE PersonType;

Accessing components of a row type: (double dots)

SELECT Person.name, Person.address..city FROM Person WHERE Person.address..street LIKE ‘%Mountain%’

34 REFERENCES We can define attributes of a row type to reference objects of other row types:

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

Following references: SELECT president->name FROM Company WHERE president->address..city=“Seattle” 35 ADTs AN EXAMPLE ORDBMS SCHEMA

create table frames (frameno integer, image jpeg, category integer); create table categories (cid integer, name text, lease_price float, comments text); create type theater_t row (tno integer, name reference complex text, address text, phone integer) types types create table theaters theater_t; create table nowshowing (film integer, theater ref(theater_t), start date, end date); create table films (filmno integer, title text, stars setof(text), director text, budget float); create table countries (name text, boundary polygon, population integer, language text)

36 COMPLEX TYPES

| User can use type constructors to generate new types: y setof(foo) y arrayof(foo) y listof(foo) y row (n1 t1, ..., nk tk) | Can be nested: y setof(arrayof(int))

37 ADTS: USER-DEFINED ATOMIC TYPES

| Built-in SQL types (int, float, text, etc.) are limited. y Even these types have simple methods associated with them (math, LIKE, etc.) | ORDBMS: User can define new atomic types (& methods) if a type cannot be naturally defined in terms of the built-in types:

create type jpeg (internallength = variable, input = jpeg_in, output = jpeg_out);

Need input & output methods for types.

–e.g., Convert from text to internal type and back. 38 | CREATE TYPE person_typ AS OBJECT (

| idno NUMBER,

| name VARCHAR2(30),

| phone VARCHAR2(20),

| MAP MEMBER FUNCTION get_idno RETURN NUMBER,

| STATIC FUNCTION show_super (person_obj in person_typ) RETURN VARCHAR2,

| MEMBER FUNCTION show RETURN VARCHAR2)

| NOT FINAL;

| /

| CREATE TYPE BODY person_typ AS

| MAP MEMBER FUNCTION get_idno RETURN NUMBER IS

| BEGIN

| RETURN idno;

| END;

| -- static function that can be called by subtypes

| STATIC FUNCTION show_super (person_obj in person_typ) RETURN VARCHAR2 IS

| BEGIN

| RETURN 'Id: ' || TO_CHAR(person_obj.idno) || ', Name: ' || person_obj.name;

| END;

| -- function that can be overriden by subtypes

| MEMBER FUNCTION show RETURN VARCHAR2 IS

| BEGIN

| RETURN person_typ.show_super ( SELF );

| END; 39 | END;

| / REFERENCE TYPES & DEREF.

| In most ORDBMS, every object has an OID. | So, can “point” to objects -- reference types! y ref(theater_t) | Don’t confuse reference and complex types! | Both look same at output, but are different!! y Similar to “by value” vs. “by reference” in PL

40 DINKEY SCHEMA REVISITED

create table frames (frameno integer, image jpeg, category integer); -- images from films create table categories (cid integer, name text, lease_price float, comments text); -- pricing create type theater_t tuple(tno integer, name text, address text, phone integer) create table theaters theater_t; -- theaters create table films (filmno integer, title text, stars setof(text), director text, budget float); -- Dinkey films create table nowshowing (film integer, theater ref(theater_t), start date, end date); create table countries (name text, boundary polygon, population integer, language text) 41 AN EXAMPLE QUERY IN SQL-3

| Clog cereal wants to license an image of Herbert in front of a sunrise: select F.frameno, thumbnail(F.image), C.lease_price from frames F, categories C where F.category = C.cid and Sunrise(F.image) and Herbert(F.image);

y The thumbnail method produces a small image. y The Sunrise method returns T iff there’s a sunrise in the picture.

y The Herbert method returns T iff Herbert’s in pic. 42 ANOTHER SQL-3 EXAMPLE

| Find theaters showing Herbert films within 100 km of Andorra:

select N.theater->name, N.theater->address, F.name from nowshowing N, frames F, countries C where N.film = F.filmno and Radius(N.theater->location, 100) || C.boundary and C.name = ‘Andorra’ and F.stars ε ‘Herbert the Worm’ y theater attribute of nowshowing: ref to an object in another table. Use -> as shorthand for deref(theater).name y Set-valued attributes get compared using set methods. 43 EXAMPLE 2, CONT.

select N.theater->name, n.theater->address, F.name from nowshowing N, frames F, countries C where N.film = F.filmno and Radius(N.theater->location, 100) || C.boundary and C.name = ‘Andorra’ and F.stars e ‘Herbert the Worm’

| join of N and C is complicated! y Radius returns a circle of radius 100 centered at location y || operator tests circle,polygon for spatial overlap

44 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 ( list of attributes and their types optional declaration of the comparison functions: =, < declaration of methods for the type ); 45 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; );

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

47 COMPLEX OBJECTS

| Unstructured complex objects: y The structure of these objects is not known to the DBMS y Only the application programs can interpret the objects

Ex: Bitmap images - BLOB (Binary large objects) y These objects require a large amount of storage and are not a part of the standard type definitions | Structured complex objects: y The object structure is defined and known to the DBMS y Object Structure is defined using type constructors (set, atom, tuple) 48 ODL

| Class Declarations y interface < name > {elements = attributes, relationships, methods } | Element Declarations y attribute < type > < name > ; y relationship < rangetype > < name > ; | Method Example y float gpa(in: Student) raises(noGrades) | float = return type. | in: indicates Student argument is read-only.

| Other options: out, inout. | noGrades is an exception that can be raised by method gpa.