You are on page 1of 25

Object-Oriented & Object-Relational DBMS

R & G (& H) Chapter 23 “You know my methods, Watson. Apply them.” -- A.Conan Doyle, The Memoirs of Sherlock Holmes

Motivation

• Relational model (70’s): clean and simple – great for administrative data – not as good for other kinds of data (e.g. multimedia, networks, CAD) • Object-Oriented models (80’s): complicated, but some influential ideas – complex data types – object identity/references – ADTs (encapsulation, behavior goes with data) – inheritance • Idea: build DBMS based on OO model

directmail marketing.. etc.Example App: Asset Management • Old world: data models a business • New world: data IS business – 1011010111010100010100111 = $$$$$! – software vendors. . entertainment industry.. – this data is typically more complex than administrative data • Emerging apps mix these two worlds.

stills.An Asset Management Scenario • Dinkey Entertainment Corp. sounds for various purposes • action figures • video games • product endorsements – database must manage assets and business data . stills. sounds – Herbert films show worldwide Herbert the Worm – Dinkey licenses Herbert videos. – assets: cartoon videos.

image BLOB.Why not a Standard RDBMS? create table frames (frameno integer. don’t move data to code! • Inefficient. too hard to express queries. . category integer) • Binary Large Objects (BLOBs) can be stored and fetched • User-level code must provide all logic for BLOBs • Performance – Scenario: client (Machine A) requests “thumbnail” images for all frames in DBMS (Machine B) – Should move code to data.

• Postgres group invented a lot of this stuff at Berkeley – And had it working in the early 90’s! – Unfortunately. but..“Object-Relational” Databases • Idea: add OO features to the type system of SQL.e. – columns can be of new types (ADTs) – user-defined methods on ADTs – columns can be of complex types – reference types and “deref” – inheritance and collection inheritance – old SQL schemas still work! (backwards compatibility) • Relational vendors all moving this way (SQL:1999). I. “plain old SQL”. it defined its own syntax before the standard • And now is not standard-compliant • Most of this stuff can be done in Postgres with analogous syntax • And Postgres has more extra goodies here than SQL:99! ..

Some History • In the 1980’s and 90’s. – Was commercialized as Illustra – Informix (a relational vendor) bought Illustra and integrated the ORDBMS features into Informix’ core server – Oracle and IBM were forced to compete with Informix – The OODBMS companies never caught on – SQL:1999 standard included many features invented in the Postquel language The Postgres research project went “open source” in 95 – Some Berkeley folks converted from Postquel to an extended SQL – The open source community took the code and ran with it IBM bought Informix a couple years ago – Hence sells 2 of the 3 leading ORDBMS implementations! • • • . Postgres “beat” OODBMSs. DB researchers recognized benefits of objects. Two research thrusts: – OODBMS: extend C++ with transactionally persistent objects – ORDBMS: extend Relational DBs with object features Postgres was a Berkeley research project. defined ORDBMSs.

ADTs An Example SQL:1999 Schema create table frames (frameno integer. director text. population integer. reference create table categories (cid integer. theater ref(theater_t) scope theaters. comments text). types create table theaters of theater_t ref is tid system generated. budget float). start date. phone integer) ref is system generated. boundary polygon. name text. create table nowshowing (film integer. stars varchar(25) array[10]. lease_price float. name text. end date). create table countries (name text. create table films (filmno integer. category integer). language text) . title text. complex address text. image jpeg. types create type theater_t as row (tno integer.

Informix (commercialized Postgres) supports setof.. listof. Postgres supports setof. stars varchar(25) array [10]) • Other obvious extensions: – listof(base) – setof(base) – bagof(base) – Not in the SQL:1999 standard. . bagof..Complex Types • use type constructors to generate new types – row (n1 t1. . nk tk) – base array [i] • can be nested: – row(filmno integer..

etc.ADTs: User-Defined Atomic Types • Built-in SQL types (int.) • ORDBMS: can define new types (& methods) create type jpeg (internallength = variable. input = jpeg_in. .) limited – have simple methods as well (math. float. LIKE.. etc. output = jpeg_out). • Not naturally composed of built-in types – new atomic types • Need input & output methods for types – convert from text to internal type and back – we’ll see how to do method definition soon. text..

name text. phone integer) – theater ref(theater_t) • Both look same at output. objects can be given object IDs (OIDs) – Unique across time and space – create table theaters of theater_t ref is tid system generated. – Some systems do this for all rows of all tables • So. can “point” to objects -. • In ORDBMS.Reference Types & Deref. address text. update. “sharing” – similar to “by value” vs.reference types! – ref(theater_t) scope theaters • Don’t confuse reference and complex types! – mytheater row(tno integer. “by reference” in PL . but are different!! – deletion.

-.images from films create table categories (cid integer. address text. name text.theaters create table films (filmno integer. title text. stars varchar(25) array[10]. create table countries (name text. name text. population integer. image jpeg. -. phone integer) ref is system generated. lease_price float. -. language text) . director text. comments text). theater ref(theater_t) scope theaters. end date). budget float). category integer). -.pricing create type theater_t as row(tno integer.Dinkey films create table nowshowing (film integer. boundary polygon.Dinkey Schema Revisited create table frames (frameno integer. create table theaters of theater_t ref is tid system generated. start date.

lease_price frames F.image).An Example Queries in SQL-99 • Clog cereal wants to license an image of Herbert in front of a sunrise: select from where and and F.image) is_Herbert(F. thumbnail(F. – The thumbnail method produces a small image – The is_Sunrise method returns T iff there’s a sunrise in the pic – The is_Herbert method returns T iff Herbert’s in pic . C. categories C F.frameno.cid is_Sunrise(F.image).category = C.

stars[1] – theater attribute of nowshowing: ref to an object in another table. Use -> as shorthand for deref(theater).name – Array index as in C or Java .title nowshowing N. 100).Another SQL-99 Example • Find theaters showing Herbert films within 100 km of Andorra: select from where and N. C. frames F.boundary) and C. countries C N.filmno Overlaps(Radius(N. N.theater->name.theater->location.film = F.theater->address. F.name = ‘Andorra’ and `Herbert the Worm’ = F.

C. F.filmno Overlaps(Radius(N. polygon for spatial overlap .boundary) and C.Example 2. 100). N. select from where and N. cont.theater->address.stars[1] • join of N and C is complicated! – Radius returns a circle of radius 100 centered at location – Overlaps compares a circle.name = ‘Andorra’ and `Herbert the Worm’ = F. frames F.film = F.title nowshowing N.theater->name.theater->location. countries C N.

New features in SQL-99 DML • Built-in ops for complex types – e. dot notation for row types • Operators for reference types – deref(foo) – shorthand for deref(foo).g. listof… – E. array indexing. bagof. • User-defined methods for ADTs • Additional vendor-specific syntax – For stuff like setof. typical set operators .g.bar: foo->bar.

name emp E.oid. • What about Emp.name from emp E.Path Expressions • Can have nested row types (Emp. called path expressions – Describe a “path” to the data • Path-expression queries can often be rewritten as joins.name) • Can have ref types and row types combined – nested dots & arrows.Dept = D. Dept D.oid D.Mgr = M.name) • Generally. (Emp->Dept->Mgr. Why is that a good idea? select from where and M. select E->Dept->Mgr.hobbies? – Analogy to XML trees .spouse. Emp M E.children.

etc.User-Defined Methods • New ADTs will need methods to manipulate them – e. crop. – expert user writes these methods in a language like C. rotate. smooth.g.class’ language ‘Java’ – Most ORDBMS bundle a JVM – C functions can be dynamically linked in . for jpeg: thumbnail. compiles them – register methods with ORDBMS: create function thumbnail(jpeg) returns jpeg as external name ‘/a/b/c/Dinkey.

select * from theater_t) – Not supported in SQL99 .g..Inheritance • As in C++. – queries on theaters also return tuples from theater_cafes (unless you say “theaters only”) • “Type extents” – all objects of a given type can be selected from a single view (e. useful to “specialize” types: – create type theatercafe_t under theater_t (menu text). – methods on theater_t also apply to its subtypes • “Collection hierarchies”: inheritance on tables – create table theater_cafes of type theater_t under theaters.

g. nor the behavior of the functions! . RunnerUp instead of MAX – For new ADTs • E.g.User Defined Aggregates • May want to define custom aggregates – For standard types • E. ColorHistogram over jpegs • An aggregate is actually a triplet of 3 user-defined helper functions – Initialize: generate a transition value – Advance: incorporate a new input value into the transition value – Finalize: convert transition value into an output value • Note that the DBMS need not understand the types of the running state.

Modifications to support all this? • Parsing – type-checking for methods pretty complex • Query Rewriting – often useful to turn path exprs into joins! – collection hierarchies →Unions • Optimization – new algebra operators needed for complex types • must know how to integrate them into optimization – WHERE clause exprs can be expensive! • select pushdown may be a bad idea .

More modifications • Execution – new algebra operators for complex types – OID generation & reference handling – JVMs and/or dynamic linking – support “untrusted” C methods – support objects bigger than 1 page – method caching: much like grouping • f(x) for each x is like AVG(major) for each major .

• Access Methods – indexes on methods.edu • GiST indexes implemented in Postgres.cs. >. not just columns – indexes over collection hierarchies – need indexes for new WHERE clause exprs (not just <. • http://gist.berkeley.Modifications. =)! • GiST can help here. cont. Informix • Data Layout – clustering of nested objects – chunking of arrays .

An Alternative: OODBMS • Persistent OO programming – Imagine declaring a Java object to be “persistent” – Everything reachable from that object will also be persistent – You then write plain old Java code.g. and all changes to the persistent objects are stored in a database – When you run the program again. – But this programming style doesn’t support declarative queries • For this reason (??). converting between Java and SQL types. OODBMSs haven’t proven popular • • OQL: A declarative language for OODBMSs – Was only implemented by one vendor in France (Altair) – XQuery is the revenge of OQL! . handling rowsets. etc. those persistent objects have the same values they used to have! Solves the “impedance mismatch” between programming languages and query languages – E.

don’t expect it to make sense! .Summary. • ORDBMS offers many new features – but not clear how to use them! – schema design techniques not well understood • No good logical design theory for non-1st-normal-form! – query processing techniques still in research phase • a moving target for OR DBA’s! – XML is an alternative for complex object features • The equivalences between SQL’s complex object support and its (future) XQuery integration are not well explored • This redundant functionality “happened to” SQL. cont.

473$9:5&$.5.

334.619.70  ':.3.6 9/9.:5 70 .4/5.54.619.0 .:4.:.5.  ':./ . :59:5.95:'.95:'9/9.9047 ..0   0.904708 070 .&59:4.6305:.6179610:.9 17.4.9:.:59: 800.34.0 174217.  2..208 .0  '.3/8*$:3780  2.80*57.2034 9:2-3.  3609.6.5965.9/9.3/8*07-079  2.

9&$.56.

5 24651699.3/ 3. ....58 #.3/ .9::659/9. 5.943   -4:3/.:569../3 :  .9.9 5..//7088  990 174234843 17.656:659.5169 19 .56.3/+07-07990472   89.::69.51.4  99.6.907 ..9/.9 90...9. .7 .78(  ../:8  90...20  90..907 4.208 .56/0..07.20 3/477.907 3.473  51.4:39708 070 12 1234 .34:. 800.

07.9:..//7088  990 174234843 17.1  %.3/ 3.20  90.1:9..3/ .1:05.9 90...943   -4:3/..91.58 #.907 4..65  "93.907 .7 .7 .3/+07-07990472  89.907 3.20 3/477.208 .473 065.78(  656!. .51:064730.95:.. 800.7:0647.0903 7636569:7.090369.4:39708 070 12 1234 . 360./:8  90.3 693.

9:5&$.!..

   3.

567:6906473..69:699950.7:  19 66  :69..516919 66 /.7:    ..7:  "79.99..515 16.656996.966.56.

9  :9./.

35169.61:69':  11.65.1514.

3:..69: .6 3:.:700:5.  69:..32:.6 /.70.679.6    .

5.5196.5.4  .: ..7:064/51  5:.9.7:.116.7: 47 :76: 5.79::65:  .996:  47.5:.196.#.

7.

6.  #.4  59..33 0..79::65:  :09/... 9 5.3317.1..7...

 800.20 1742025 059 25 070 059 4/ .36.6611.47 03195 6//:  5..6 .56.5/99...5 .3/ 7 4/  .9 3..9 059 7 3.20 1742025 800...:65: :.79::6589:0./6.9: .

:9.

5.64.61:.3 0967 96. .9439:2-3.:4.809073.573.:.4/5.901:3.61:5. :466.61:.3. 32 06473:.0  79.70.61:  !':33514.4  9:."% & .:99... .9 4..3.20 .4    697. 50 709:73850 .51 .

-.

3:..0 .40.3335215 ..  6:..65:0.30 .  50.5/15."% &/513.88 .

3¾..::/..:6.7: .907*.9:.907*9 :3/0790.59.73:964 .50  :5 :3..336/0..907..70....6:70.  !6.3:6.9.1964.0....907*9 203:909   4..15&$ .5.:7769.9078  89:65..70.7:  6330.9095090.9:653  '7..70.9.90:¾59.: 53::6:.5065.5/:30.-090.6.:¾  .9.3:69.5.95./3: .61:65.1084195090..659.773.10*9:3/0790...909. 964. :53   :30...

9..973.5.6150:.:  ..51..16   695':    6369:...4697:  5...91.33.:9519.64.:  69:.:.6:9.69.7:    %55975:.9...0.

359...50..51..3  1.35.9.505069769.9....9555:.5:.557..7..65: .6.. &5156.65.65.3  5.5:...7:6 .151 37950...30659.696.65 . 569.6..35.65:  5.3  !6..56.9../.519:.5:..

9:5  .610.65:.6:7769...:  #.33.7.

5  6.65  %03..679.06473  $9%9...2566.65..9.90:F565:  "7.665:  06330.45..0025694.:79:0.69:5116906473.5/75:  :30. .6 67.6.957.11.4.65  5.5:3.61:79../.79:5.4.7:  4:./.3/9..659.7:1654.

  4.:/9.694610.610.6/0.403525  :7769.5.3/9.69:6906473.5135   :.679.04.14.9:.0540329675    69.516915.69 69..65 9950.7:  "59.57..69 .61:  :7769.65  5...0:32 4.65:  0.

61:  51:654.61: 56.99.06345:  51:6906330..:  05256.90:  5151:695%03.  03:.9565:.9: 5694  .5379  .      &'0.610.: .7:...15#6:.16/0.. 0: /923 1  &'51:47345.  00:: .6.:.659.65: 065.:79: 56.:..

5.0¾/. .5.330."" &  #9::.89:  69.  6.:1..0.73.9:...9  $9:.6..3:6/79::..:9.1/65516959.  9.59.5.471.79657673..6915.5:.:.51&$.445:.5.4.5/.6/0.51.95.513596:.6/0.5..:  5695.:..9.3.5103..7969.316:5.:7769.504:4.5631.6/79::.5.061 .6/0.:65  "" &:.6:79::. 79::./3964.5..9.5.6/0.69"" &:  .5.:    0659.:  .53.5.""7969.1.:.33...:7969.445  4.4.5 .956"$ .6.103.:65347345.9   "$103.57969.445 3. &63:.7: ...59...51893..95.3:.:./.50 3.0  .

 "% &69:4..56.&44.1:5.9:  /.33519:.661  !6661360.6:.31:5.058:56.9 065.55.03.4  :04.6969565.96.

:.

5694.3.

: .95.:  .907.3359:.9 $95..:7769.70.65..9...058::.350:/..9:  '8.465..69"%:   :.7751..65.3373691  ':9151..64.694  897960::5.5&$:064736/0.9.6&$ 165.5. .3.5.956.3.69064736/0.2:5: .51 .50.