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 <name> { attributes: <type> <name>; relationships <range type> <name>; 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 <Star> stars inverse Star::starredIn; float lengthInHours raises(noLengthFound); starNames (out Set <String>); otherMovies (in Star, out Set<Movie>) 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<Loans> borrowed inverse Loans::borrower; relationship Set<Branch> 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<type>. 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<Customer> 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> loans-granted inverse Loans::belongs-to; relationship Set<Customer> 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<Course> 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<Beer> 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<Bar> 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<Drinker> 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