OODBMS 1/61 Part 3: Object-Oriented Database Management Systems Thomas Neumann
OODBMS 2/61 Literature R. Catell et al. The Object Data Standard: ODMG 3.0 Morgan Kaufmann, 2000 A. Kemper and G. Moerkotte. Object-Oriented Database Management: Applications in Engineering and Computer Science Prentice Hall, 1994 M. Stonebreaker. Object-Relational DBMSe: The Next Great Wave Morgan Kaufmann, 1996
OODBMS 3/61 Introduction Object-Oriented programming Why not relational? OODBMS ODMG 3.0 OQL Object-Relational DB Overview
OODBMS 4/61 1.1 Introduction most currently used DBMSs relational assume large sets of uniform data not suited for heavily structured data OODBMSs can handle these firms don t want to switch relational DBMS become object-relational as compromise
OODBMS 5/61 2.1 Object-oriented programming imperative languages Assembler, Fortran, C etc. sequence of commands performs operations on data object-oriented languages Smalltalk, C++, Java etc. object: combination of code and data offer an interface, hide the implementation concentrates on the algorithms
OODBMS 6/61 2.1 Object-oriented programming (2) higher level of abstraction concentrates on behavior of objects (ADTs) easier code reuse better maintainable
OODBMS 7/61 2.2 OOP - data encapsulation E.g. class Stack { private... public void push ( Object o ) ; public Object pop ( ) ; } objects define behavior implementation not visible implementation can easily be changed
OODBMS 8/61 2.3 OOP - inheritance/substitutability class F i l e { public s t r i n g getpath ( ) ; } class NFAFile extends F i l e { public s t r i n g g e t S e r v e r ( ) ; } NFSFile has all features of File NFSFile can be used where File is expected code for File can handle different files code can be reused
OODBMS 9/61 2.5 OOP - polymorphism E.g. class Container { public int g e t S i z e ( ) ; } class L i s t extends Container { public int g e t S e r v e r ( ) ; } derived class can change behavior still same interface substitutability allows generic programming
OODBMS 10/61 3.1 Why not relational? RDBMSs store data in tables operate on sets of uniform data similar to records in imperative languages OOP usually uses more complex data RDBMS cannot store that efficient
OODBMS 11/61 E.g. 3 entities: Vehicle Car is-a Vehicle Bicycle is-a Vehicle Problems: which relations? queries about all vehicles? redundancy? 3.2 Generalization
OODBMS 12/61 E.g.3 entities PostalCode Address contains PostalCode Firm contains Address Problems different relations? different entities? contained in different entities? queries? 3.3 Aggregation
OODBMS 13/61 E.g. Person.Phone Car.ColorsPossible Database.Administrators Problems not supported by RDBMS must use relations cumbersome performance 3.4 Set-valued data
OODBMS 14/61 E.g. coordinates distance rotate translate Problems only UDTs/UDFs not complex objects separate from application cumbersome 3.5 Behavior
OODBMS 15/61 3.6 Impedence Mismatch RDBMSs interpret data in terms of sets applications interpret data in terms of (linked) records data access has to be mapped cumbersome performance
OODBMS 16/61 4.1.1 OODBMS stores application data native data access eliminates I/O code blurs the distinction between application and DBMS natural storage for OO languages
OODBMS 17/61 4.1.2 OODBMS (2) Wanted features (not all OODBMSs provided all of them) persistent objects representation independence transactions queries client/server Persistent languages provide a subset
OODBMS 18/61 4.2.1 Persistent objects - OID (1) In a relational database: employee name floor Smith 2 After department name floor Marketing 1 Research 2 update department set f l o o r=f l o o r +1 Smith works in Marketing. linking using values identity through contents
OODBMS 19/61 4.2.1 Persistent objects - OID (2) In an object-oriented database employee department OID name floor OID name department oid 2 Marketing 1 oid 1 Smith oid 3 oid 3 Research 2 After an update Smith still works in Research. linking using a unique id object identity object independent of values
OODBMS 20/61 4.2.2 Persistent objects - OODBMS vs. RDBMS A rough comparison: OODB object type (extent) OID SQL tuple relation key RDBMSs think in (multi-)sets OODBMSs think in distinct objects a key is unique in a single relation an OID is unique in the whole database
OODBMS 21/61 4.2.3 Persistent objects - API application objects map directly to database objects database access is transparent database ensures pointer consistency persistence either explicit or by reachability
OODBMS 22/61 4.3 Representation independence objects not BLOBs database knows the schema application vs. internal representation different programming languages little endian vs. big endian
OODBMS 23/61 As relational databases: ACID atomicity consistency isolation durability 4.4 Transactions
OODBMS 24/61 4.5 Queries in RDBMSs data is accessed using queries in OODBMSs queries not required direct navigation possible but queries easier to use queries more efficient
OODBMS 25/61 4.6 Client/server application and database separated optional network connection multi-user prevents some naive implementation techniques
OODBMS 26/61 5.1 ODMG 3.0 industry standard for OODBMSs version 1.0 1993, 3.0 1999 ODL to describe objects OQL as query language language bindings for C++, Smalltalk and Java currently only Java binding commonly used
OODBMS 27/61 5.2 Developing general applications for OODBMSs 1. analysis/conceptual/logical design 2. physical database design in ODL 3. ODL is used to create code for application language 4. application language accesses objects via ODMG API 5. user code and generated code compiled and links Pros: language independent, rich semantics Cons: generated code, somewhat inconvenient
OODBMS 28/61 5.3 Developing Java applications for OODBMSs 1. analysis/conceptual/logical design 2. physical database design directly in Java 3. application uses objects like normal Java objects 4. application compiled 5. database features by post-processing.class files Pros: convenient, no generated code Cons: no formal specification, language dependent, less semantics
OODBMS 29/61 5.5 ODL - example module traffic { class Vehicle { }; class Car : Vehicle (extent cars) { attribute long kms; relationship Person owner inverse Owner::cars; // Operations }; class Person (extent persons) { attribute string name; attribute date birth; relationship set<car> cars inverse Car::owner; }; }
OODBMS 30/61 5.6 ODL specifies data types replaces explicit create table also specifies relationships more semantically rich than for example Java operations can also be specified would require code in database (wishful thinking)
OODBMS 31/61 ODL specification: 5.7 ODMG Java API - example (1) class Node { attribute long value; attribute Node left; attribute Node right; };
OODBMS 32/61 generate Java code: 5.7 ODMG Java API - example (2) public class Node { public int value; public Node left; public Node right; static Node createsometree(); // User code static void traverse(node root); // User code }; // Some DB specific code...
OODBMS 33/61 5.7 ODMG Java API - example (3) public class StoreTree { public static final void main(string[] args) { try { Implementation impl=mydb.getimplementation(); Database db=impl.newdatabase(); db.open( test,database.open READ WRITE); Transaction trans=impl.newtransaction(); trans.begin(); db.bind(createsometree(), root ); trans.commit(); db.close(); } catch (Exception e) { e.printstacktrace(); } } }
OODBMS 34/61 5.7 ODMG Java API - example (4) public class RetrieveTree { public static final void main(string[] args) { try { Implementation impl=mydb.getimplementation(); Database db=impl.newdatabase(); db.open( test,database.open READ ONLY); Transaction trans=impl.newtransaction(); trans.begin(); traverse((node)db.lookup( root )); trans.commit(); db.close(); } catch (Exception e) { e.printstacktrace(); } } }
OODBMS 35/61 5.8 ODMG - Interface public interface Implementation { Transaction newtransaction(); Database newdatabase(); OQLQuery newoqlquery(); DList newdlist(); DBag newdbag(); // Some more for collections and helpers } abstraction from the actual implementation allows to change the DBMS easily
OODBMS 36/61 public interface Transaction { void begin(); void abort(); void checkpoint(); void commit(); void lock(object o,int mode); // Some more } 5.9 ODMG - Transaction interface for transaction management every database operations requires an active transaction
OODBMS 37/61 5.10 ODMG - Database public interface Database { void open(string name,int mode); void close(); void checkpoint(); void bind(object o,string name); Object lookup(string name); void unbind(string name); void makepersistent(object o); void deletepersistent(object o); } interface to the database handles actual manipulation
OODBMS 38/61 public interface OQLQuery { void create(string oql); void bind(object parameter)); Object execute(); } OQL interface allows parameter binding result depends on query 5.11 ODMG - OQLQuery
OODBMS 39/61 5.12 ODMG - collections persistent collections DSet/DBag/DList/DArray/DMap base class DCollection implement java.util.{set List Map} additional set operations suited for database storage
OODBMS 40/61 6.1 OQL declarative query language standard query language for OODBMSs aims to be similar to SQL cleaner language can handle set value attributes pointer chasing
OODBMS 41/61 6.2 simple OQL 5 Smith 6*7 Doesn t require a select statement, any expression can be used
OODBMS 42/61 6.3 path expressions car car.owner car.owner.birth.year car.owner.birth-today() Requires a join in SQL. An OODBMS is free to use a join or not.
OODBMS 43/61 6.4 object creation Person(name: Smith birth:today()) struct(year:2002 month:10 day:28) bag(1,2,2,3,4) set(1,2,3,4) list(4,3,6,3)
OODBMS 44/61 6.5 UNDEFINED assume that car.owner is nil. then car.owner.birth results in UNDEFINED. any comparison with UNDEFINED is false any other operation results in an exception check for undefined: is undefined(car.owner.birth)
OODBMS 45/61 6.6 aggregation min, max, avg and sum can be used with sets of numbers count can be used for any set E.g. avg(cars.kms) count(persons)
OODBMS 46/61 6.7 select-from-where select from where p persons p p.name= Smith Result: bag<person> select distinct p from persons p where p.name= Smith Result: set<person>
OODBMS 47/61 6.8 syntax variations The following expressions are equivalent: select distinct p from persons p where p.name= Smith select distinct p from p in persons where p.name= Smith select distinct p from persons as p where p.name= Smith
OODBMS 48/61 6.9 joins and nested queries select distinct p,(select avg(kms) from p.cars) from persons p, (select c from cars c where c.kms>100000) as c where c in p.cars joins as in SQL nested queries more powerful nesting allowed at any place
OODBMS 49/61 6.10 quantifiers select from where select from where p persons p exists c in p.cars: c.kms>100000 p persons p for all c in p.cars: c.kms<10000
OODBMS 50/61 6.11 set comparisons (select from where <= (select from where p persons p exists c in p.cars: c.kms>100000) p persons p p.birth.year<1970) <= tests for subset also possible: <, =, >, >=
OODBMS 51/61 6.12 collection operations (select from where intersect (select from where p persons p exists c in p.cars: c.kms>100000) p persons p p.birth.year<1970) also possible: union, except can be used for any collection
OODBMS 52/61 6.13 grouping select from p (select p as p, sum(select kms from p.cars) as kms from persons p) group by many: kms>100000 normal: (10000<=kms) and (kms<=100000) few: kms<10000 Result type: set<struct(many: bool, normal: bool, few: bool, partition: bag<person>)>
OODBMS 53/61 definition: 6.14 named queries define select from where drivers(min) as p persons p (select sum(kms) from p.cars)>=min usage: select p from p in drivers(100000) where p.birth.year > 1980
OODBMS 54/61 7.1 object-relational DBMSs currently RDBMSs are used OO features would be nice / are required object-relational DBMS offer some OO features currently each vendor provides its own features SQL-99 tries to standardize currently OO features are very limited
OODBMS 55/61 7.2 UDTs create type coord as long decimal(8,4), lat decimal(8,4) not final method distance(c coord) returns decimal(8,4); Usage: create table cities ( name varchar(100), pos coord); insert into cities values( Mannheim,coord(9.29,49.29));
OODBMS 56/61 7.3 Methods for UDTs create method distance ( c coord) returns decimal (8,4) deterministic contains sql for coord... Usage select from where a.name, b.name cities a, cities b a.pos.distance(b.pos)<50 and a.name<b.name
OODBMS 57/61 create table positions of coord ref is oid; create table cities ( name varchar(100), pos ref(coord)); 7.4 Typed tables based on UDTs insert into positions values(9.24,49.29) insert into cities select Mannheim,p from positions p where p.lat==9.24 and p.long=49.29; elements of positions are objects of their own
OODBMS 58/61 7.5 Inheritance with UDTs create type hcoord under coord as height decimal(8,4), not final; inherits all properties of coord limited substitutability no (dynamic) polymorphism
OODBMS 59/61 7.6 Distinct types create type EURO as decimal (8,2) final create type USD as decimal (8,2) final no automatic conversion explicit casts required
OODBMS 60/61 7.7 Further UDT features create table... under... create cast create ordering create transform (host language interface)
OODBMS 61/61 Summary OODBMS allow efficient handling of structured data comfortable API and query functionality ORDBMS as compromise between OODBMS and RDBMS future RDBMS will be OR, OO features will increase