Idea Transcript
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
Overview • Introduction • Object-Oriented programming • Why not relational? • OODBMS • ODMG 3.0 • OQL • Object-Relational DB
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. c l a s s 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 ( ) ; } c l a s s 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 ( ) ; } c l a s s L i s t extends C o n t a i n e r { 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
3.2 Generalization E.g. 3 entities: • Vehicle • Car is-a Vehicle • Bicycle is-a Vehicle Problems: • which relations? • queries about all vehicles? • redundancy?
OODBMS
12/61
3.3 Aggregation E.g.3 entities • PostalCode • Address contains PostalCode • Firm contains Address Problems • different relations? • different entities? • contained in different entities? • queries?
OODBMS
13/61
3.4 Set-valued data E.g. • Person.Phone • Car.ColorsPossible • Database.Administrators Problems • not supported by RDBMS • must use relations • cumbersome • performance
OODBMS
14/61
3.5 Behavior E.g. coordinates • distance • rotate • translate Problems • only UDTs/UDFs • not complex objects • separate from application • cumbersome
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
department
name
floor
Smith
2
name
floor
Marketing
1
Research
2
After 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
department
oid1
Smith
oid3
OID
name
floor
oid2
Marketing
1
oid3
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
SQL
object
tuple
type (extent)
relation
OID
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
4.4 Transactions As relational databases: ACID • atomicity • consistency • isolation • durability
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 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
5.7 ODMG Java API - example (1) ODL specification: class Node { attribute long value; attribute Node left; attribute Node right; };
OODBMS
32/61
5.7 ODMG Java API - example (2) generate Java code: 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
5.9 ODMG - Transaction public interface Transaction { void begin(); void abort(); void checkpoint(); void commit(); void lock(Object o,int mode); // Some more } • 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
5.11 ODMG - OQLQuery public interface OQLQuery { void create(String oql); void bind(Object parameter)); Object execute(); } • OQL interface • allows parameter binding • result depends on query
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 select distinct p from persons p where p.name=”Smith” Result: set
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
p persons p exists c in p.cars: c.kms>100000
select from where
p persons p for all c in p.cars: c.kms