Object-Oriented Data Bases [OODBs] Data Model [OODM] Prog. Langs [OOPLs]

1. Object-Oriented Data Bases [OODBs] Data Model [OODM] Prog. Langs [OOPLs] Non-OO data models believed inadequate for eg - CAD/CAM, CIM - Image, Graphics, Multimedia DBs - uniform access to multiple DBs CAD/CAM, CIM, Multimedia applications often characterised by • more complex structures • transactions of longer duration • awkward new data types (images, large texts, audio, video, trees, …) • need for nonstandard application-specific operations, eg image matching http://csiweb.ucd.ie/staff/acater/comp30150.html

2. OODMs (OO Data Models) give a designer power to specify - structure of objects - operations on objects Object Classes encapsulate behaviour: • implementation details are hidden • operations are manifest (just like Abstract Data Types) http://csiweb.ucd.ie/staff/acater/comp30150.html

3. OOPLs have inheritance and message passing. • Pure OOPLs, eg SMALLTALK, have explicit OO design; • Hybrid OOPLs, eg C++, augment HLL with OO features. OOPLs allow programs to create and manipulate transient objects. OODBs interface with one or more OOPL • to provide persistent objects • to allow sharing among programs and applications They need to offer DB features such as recovery, concurrency, security. http://csiweb.ucd.ie/staff/acater/comp30150.html

4. Object identifiers (cf keys, RM/T surrogates) provide for • Correspondence between real-world objects and DB objects • The sameness of an entity described in different ways needs to be established somehow: • eg student exam number for written examinations in UCD needs to be tied to name+class+year for continuous assessment work • Possibly, repeated access by program to the same object in multiple sessions • Links between complex objects and their component parts, etc. Object structure may be arbitrarily complex, cf. scattering information across several relations. http://csiweb.ucd.ie/staff/acater/comp30150.html

5. Instance variables roughly resemble relational attributes - but perhaps encapsulated in methods and so not directly visible - may hold arbitrarily complex structures, not just atomic values Relationships between objects are representable (1) by methods that locate related objects - strict, ideological encapsulation (2) citing object identifiers of related objects within self - clearly identifies relationship. Especially valuable in complex databases with multiple relationships, makes related objects visible to users. http://csiweb.ucd.ie/staff/acater/comp30150.html

6. Designer (of suite of application programs sharing data) can define operations on a class. (Must there be an operation defined for every simple kind of retrieval?) Op. signature (interface) - name & argument types Op. method (body) - the implementation Op. invocation by passing message to object, giving op name and arguments. This encapsulation allows changing object structure and method implementation without disturbing external programs - a kind of Logical Data Independence. http://csiweb.ucd.ie/staff/acater/comp30150.html

7. Class hierarchies allow method inheritance. Operator overloading / polymorphism is commonplace - methods may be specialised on object classes. OODB may • have capabilities for dealing with multiple versions of the same object • useful in design, engineering (and software engineering) applications • support schema evolution • changing data types • adding new types • adding new relationships http://csiweb.ucd.ie/staff/acater/comp30150.html

8. OODB provides unique, immutable object identifiers [OIDs]. • Strict Ideology - everything has an OID • Common Practice - scalar values stand for themselves States of objects can be built by type constructors: • atom, tuple, set commonly • list, array, bag less commonly An OO DDL defines classes as a combination of • (nested) constructor expressions • operations http://csiweb.ucd.ie/staff/acater/comp30150.html

9. http://csiweb.ucd.ie/staff/acater/comp30150.html

10. Objects are made persistent by one of two methods: • giving them a unique persistent name, in the schema, or • making them reachable from another object which is (or will be made) persistent • using operations like “add to list” • This implies a need for Garbage Collection of persistent object store (Elmasri & Navathe do not mention this) Programs may make transient copies of persistent objects; and may create objects and cause them to become persistent - by linking them to another persistent object, maybe a named one. http://csiweb.ucd.ie/staff/acater/comp30150.html

11. OODBMS may need to store and retrieve large unstructured complex objects, such as • image bitmaps • sound recordings • long text strings Such things are often treated as "Binary Large Objects" - BLOBs http://csiweb.ucd.ie/staff/acater/comp30150.html

12. DBMS does not know about any structure within BLOBs; • only an application can interpret their meaning • DBMS alone cannot be expected to selectively retrieve them on the basis of their content • DBMS can retrieve them only when given the object id • BLOBs are not of standard DBMS types • BLOBs often require considerable storage • being large, DBMS and application may conspire to transmit/supply part of object before all is retrieved http://csiweb.ucd.ie/staff/acater/comp30150.html