![Complex Types
• use type constructors to generate new types
– row (n1 t1, ..., nk tk)
– base array [i]
• can be nested:
– row(filmno integer, stars varchar(25) array [10])
• Other obvious extensions:
– listof(base)
– setof(base)
– bagof(base)
– Not in the SQL:1999 standard. Postgres supports setof, Informix
(commercialized Postgres) supports setof, bagof, listof.](https://image.slidesharecdn.com/adbms19objecttechnologyinrdbms-201013101803/85/Adbms-19-object-technology-in-rdbms-7-320.jpg)
Adbms 19 object technology in rdbms
- 1. Advance Database Management Systems : 19 Object Technology in RDBMS Prof Neeraj Bhargava Vaibhav Khanna Department of Computer Science School of Engineering and Systems Sciences Maharshi Dayanand Saraswati University Ajmer
- 2. 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
- 3. Example App: Asset Management • Old world: data models a business • New world: data IS business – 1011010111010100010100111 = $$$$$! – software vendors, entertainment industry, direct- mail marketing, etc... – this data is typically more complex than administrative data • Emerging apps mix these two worlds.
- 4. Why not a Standard RDBMS? • 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, don’t move data to code! • Inefficient, too hard to express queries. create table frames (frameno integer, image BLOB, category integer)
- 5. “Object-Relational” Databases • Idea: add OO features to the type system of SQL. I.e. “plain old SQL”, but... – 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). • Postgres group invented a lot of this stuff at Berkeley – And had it working in the early 90’s! – Unfortunately, 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!
- 6. Some History • In the 1980’s and 90’s, 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. Postgres “beat” OODBMSs. – 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!
- 7. Complex Types • use type constructors to generate new types – row (n1 t1, ..., nk tk) – base array [i] • can be nested: – row(filmno integer, stars varchar(25) array [10]) • Other obvious extensions: – listof(base) – setof(base) – bagof(base) – Not in the SQL:1999 standard. Postgres supports setof, Informix (commercialized Postgres) supports setof, bagof, listof.
- 8. ADTs: User-Defined Atomic Types • Built-in SQL types (int, float, text, etc.) limited – have simple methods as well (math, LIKE, etc.) • ORDBMS: can define new types (& methods) create type jpeg (internallength = variable, input = jpeg_in, 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...
- 9. Reference Types & Deref. • In ORDBMS, 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 -- reference types! – ref(theater_t) scope theaters • Don’t confuse reference and complex types! – mytheater row(tno integer, name text, address text, phone integer) – theater ref(theater_t) • Both look same at output, but are different!! – deletion, update, “sharing” – similar to “by value” vs. “by reference” in PL
- 10. User-Defined Methods • New ADTs will need methods to manipulate them – e.g. for jpeg: thumbnail, crop, rotate, smooth, etc. – expert user writes these methods in a language like C, compiles them – register methods with ORDBMS: create function thumbnail(jpeg) returns jpeg as external name ‘/a/b/c/Dinkey.class’ language ‘Java’ – Most ORDBMS bundle a JVM – C functions can be dynamically linked in
- 11. Inheritance • As in C++, 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; – 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.g., select * from theater_t) – Not supported in SQL99
- 12. User Defined Aggregates • May want to define custom aggregates – For standard types • E.g. RunnerUp instead of MAX – For new ADTs • E.g. 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, nor the behavior of the functions!
- 13. 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, don’t expect it to make sense!
- 14. Assignment • Explain he basic concepts of ORDBMS