Object-Oriented Databases

1. Object-Oriented Databases • Record-oriented data models are powerful when applied to traditional database applications • However in a relational model, • data is organized as a flat tuple • the schema are relatively static • relationships among data must be explicitly specified as integrity constraints • traditional models lack functionality in supporting advanced database applications • CAD/CAM and CIM, Image and graphics, Geographic and scientific, multimedia, documents, etc. • Characteristics and requirements • complex structures of objects • new data types for unstructured data (e.g. BLOB) • reactive(endless) activities • long-duration (open-ended) activities • collaborating (cooperative) activities OO Data models and OO database systems are proposed to address these requirements

2. Systems and Interfaces • experimental prototypes • ORION (MCC), OpenOODB (Texas Instruments), IRIS(HP), ODE(ATT Bell Labs), ENCORE/ObServer (Brown), ... • commercial OODB Systems • GEMSTONE/OPAL (Servio Logic), O2 (O2 Technology), ObjectStore (Object Design), ... • OO Shells or Interfaces • Paradox, Access, ..

3. Concepts are adopted from OO programming languages • Object • is an instance of abstract data type (ADT) • hides the internal data structure (information hiding) • can be accessed and manipulated by the application using a set of operations specific to the ADT (encapsulations) • Objects in programming languages are transient • exist only during program execution • Objects in DB are persistent • they are persistent and can be shared by a number of programs • Class • collections of objects, either implicitly or explicitly specified • contain associated methods, which are algorithms specifying how the objects in that class are to be manipulated • Hierarchy • imposes an acyclic graph structure on the set of classes • an OODBS supports an interface to one or more OO programming languages providing persistent and shared object capabilities while treating transient and persistent objects uniformly • there is no single OO data model. However, there is a set of concepts that an OO data model and OODB must support OO Concepts

4. Example Hierarchies Documents Museums Image Word Art Raw text Science Natural History HTML Smithsonian IBM PC Mac Metropolitan New York Baltimore Aquarium

5. OO Concepts (continued) • Object Identifier: a unique and immutable system-wide id (not true with relational data model) • OODB maintains a direct correspondence between real-world and database objects • Object structure can be of arbitrary complexity in order to contain all significant information (in relational the information is scattered over many relations) • instance variables • Object internal structure includes the specification of instance variables that hold its state. • instance variables could be complex objects themselves • type constructors • complex object structures can be constructed by recursively applying a set of basic type constructors such as tuple, set, list, and bag • encapsulation • complete encapsulation: only a specific set of predefined operations or functions can be applied on a particular object • assumes object independence • does not permit explicit specification of relationships between objects

6. Objects • An object is defined as a pair: (id, values) • Example: • declare b2 • values [author = John Smith, • url = http://www.somewhere.com/ • date_created = (15, Jan, 1999) • date_last_modified = (25, Jan, 1999) • Types • Record type, Set type, List type • Examples: • [author: string; • url: urltype; • date_created: datetype; • date_last_modified: datetype] • [address: string; • director: string; • special_exhibits: {string}; • affiliated_museums: {Oid_set}]

7. Operations on Objects • Each operation has two parts • (1) signature or interface: specifies name and arguments of the operation (externally visible) • (2) method or body: specifies the implementation of the operation (externally invisible) • Operations can be invoked by passing a message to an object • objects' internal structure and operations' implementation can be changed without affecting the programs that access them • This provides encapsulation

8. Types, Class Hierarchy and Inheritance • Object type: set of allowable values • Object class: collection of objects meaningful in an application • New types and classes can be specified based on existing ones • Inheritance: new types and classes inherit much of the structure and operations from the type/class they are derived • incremental development of system data type is supported • ability to reuse existing type definitions and implementations

9. Object Definition Language (ODL) • Simple language within which objects and interfaces can be defined • ODL provides a formal syntax to access the signatures of the objects so that external programs wishing to access/manipulate the object using the methods provided by the object • Example: • interface html:documents • (extent html_documents • keys url: persistent • {<properties> • <operations>} • );

10. Object Query Language (OQL) • If Q is expressed in SQL, then Q is also a valid OQL query • SQL queries can access only flat relational tables • In contrast, objects may have a nested structure, as well as include fields that contain collection types - sets, lists, .. OQL facilitates access to such data types • Examples: • select struct(field1:x.url, field2:x.link) • from Word x • where x.author = “John Smith” • select y.author • from • (select x.link • from Word x • where x.author = “John Smith”) y

11. Object-Relational Systems • Relational databases have proved very useful in querying flat data • Is it possible to extend the relational model to handle complex data? • Yes, The resulting paradigm is object-relational • Example: • Consider a bank relation schema • (Fname, Lname, AccType, Trans, Amount, Day) • and a crime relation schema • (SSN, FirstName, LastName, Conviction, Day) • Suppose we extended both these schemes to include images as follows: • (Fname, Lname, AccType, Trans, Amount, Day, PIC) • (SSN, FirstName, LastName, Conviction, Day, PIC)

12. Example Continued • If a customer reports that her ATM card was stolen and she did not make the last withdrawal • To verify, the bank needs to look at the surveillance image and see if it is that of the customer • If not, the next logical step for the police to perform is to attempt check if there is a match between the image in surveillance record with any image in the crime database • This needs execution of the query • “Select all tuples in the crime relation that match the image in customer record” • SQL cannot support such query directly because the comparison operator “match” is not supported by a relational database • An object db language cannot be used either because the data is not stored in an object-oriented db

13. Object-Relational Scheme • Object relational scheme: • (A1:T1, … An:Tn) • where Ai’s are attribute names and Ti’s are objects • Example: • (Fname:str, Lname:str, AccType:int, Trans:tt, Amount:real, Day:date, PIC:image) • (SSN:ssntype, FirstName:str, LastName:str, Conviction:str, Day:date, PIC:image) • object conditions • match(image1,image2) > 0.7; • match(image1,image2) > match(image3,image2); • Query • select Fname,Lname • from Crime C, Bank B • where match(B.image1,C.PIC) > 0.9

14. Commercial Object-relational Systems • Informix • offers a variety of datablades for image db, face recognition, audio data handling, document processing, video processing, spatial db • DB2 • offers similar features called extenders • Oracle • Sybase • Uni-Sql and Ominiscience employ O-R technology