ObjectOriented Databases and Related Technology

1
Object-Oriented Databases(and Related Technology)

• CS 95 Advanced Database Systems
• Handout 5

2
Introduction

• The relational DB model (RDBM) has some
  limitations, particularly with semantics
  (meaning) and multimedia.
• Semantic limitation can add functionality but
  depart from mathematical basis of the model.
• Multimedia limitation large binary files, an
  historic limitation,
• generally addressed with BLOB types (Binary Large
  OBjects)
• BLOBs are basically treated as just a (large)
  stream of bytes

3
Example

• Consider the example of an invoice
• In the RDBM, we treat the invoice table as the
  invoice.
• Really the invoice is a much more complex object.
  To reconstruct this object in RDBM requires 5 (or
  6) joins.

4
Object-Oriented Databases

• A basic aim of OODB is to "raise the level of
  abstraction". That is, to provide access to data
  via methods that hide the complexity of low level
  access.
• Applications suited to OODB tend to be those that
  require complex SQL queries
• Computer-aided design and manufacturing (CAD/CAM)
  
• Computer-aided software engineering (CASE)
• Geographic information systems (GIS)
• Document storage and retrieval

5
Some 'Standard' OODB Concepts

• Object
• real world entity, has attributes and methods
• Classes
• for objects which share the same attributes and
  methods, e.g. person
• defines the structure of the object
• basically corresponds to a table in a RDBMS,
  although Date disagrees and refers to this as the
  First Great Blunder in 7th Ed. Section 25.2, pp
  865-872. The same argument is given in his 6th
  Ed. Section 25.4, pp 693-702 but with the less
  pressing heading Relations vs. Objects.
• Object instance
• an actual instance of an object
• e.g., an individual person's data

6
Some 'Standard' OODB Concepts

• Object identifier (OID)
• system-generated identifier
• not part of the object, somewhat like a key in
  RDBM
• OID lasts for the lifetime of the object
• in PostgreSQL this is a sequential number that is
  unique for all objects within the system.
• OIDs are used for references from one table into
  the next.
• Methods
• the interface to an object
• contains programming code (of some sort)
• similar to a function

7
Some 'Standard' OODB Concepts

• Complex objects
• the value of each object can be an object or set
  of objects referred to by OIDs
• eg attribute of a person may be children, which
  is a set of OIDs of other persons
• Encapsulation
• an abstraction that forces a separation between
  the external interface and the internal
  implementation
• hides unnecessary details of implementation
• allows code and data to be packaged together
• each object has methods (allowed
  functions/procedures)
• methods provide a visible (public) interface and
  a hidden (private) implementation

8
Some 'Standard' OODB Concepts

• Inheritance
• classes can be a subclass of another class e.g.,
  car of vehicle, the subclass inherits the
  attributes and methods of its superclass. e.g.,
  PostgreSQL CREATE TABLE person    (name
  varchar(30),     dob date)-- person has 2
  attributes CREATE TABLE student    (course
  varchar(20))    INHERITS (person) -- student
  has 3 attributes
• In PostgreSQL the select statementSELECT
  FROM personwill retrieve all matching rows
  from person and all classes under its inheritance
  hierarchy, i.e.,something like  person UNION
  ALL student

9
Some 'Standard' OODB Concepts

• Private and Public interface
• Private instances are only available to methods
  of the class
• Public instances are available to all users
• Refers to data and methods.

10
Object Data Model example
11
Object Data Model example

• This model shows
• A Person can have up to 2 Parents that refers
  back to the Person class i.e., parents are also
  an instance of a person The system would store 2
  oids in the Parents attribute
• A person can have multiple Children who are also
  persons The system would (somehow) store a set
  of oids under the Children attribute
• The Age() method returns the age of a Person
  instance, probably calculated from the stored DOB
  
• Classes Student and Professor inherit the
  attributes and methods of Person plus have
  additional attributes
• So you can obtain the Age() of a Student or
  Professor

12
Object Data Model example

• This model shows
• The attribute Takes in the Student class would be
  a set of oids from the Course class
• Similarly for the Teaches attribute in the
  Professor class
• The "Has Students" attribute of the Course class
  contains a set of oids of students enrolled in
  that course
• This provides efficient two-way access for - all
  courses a student is enrolled in - all students
  enrolled in a course

13
Object Data Model example

• A hypothetical syntax for the class definitions
  of Person and Student may be Class Person
  PUBLIC(Name   Text,           Parents  REF (
  Person, Person ),           DOB      Date,
            Children REF ( SET ( REF ( Person )))
  )    METHODS ( Age ( REF Person.DOB )  ... code
  ... )
• Class Student PUBLIC ( Takes    REF ( SET ( REF
  ( Course ))) ) INHERITS ( Person )

14
Advantages/Disadvantages of OODBMS

• Advantages
• Fast navigation
• Advanced features built into the OODBMS -
  inheritance, methods, user-definable data types
  etc.
• Integrated database programming language.
  Unfortunately, current DB languages are typically
  procedural (3GL).
• Disadvantages
• Incomplete theory and standards. Hence OODBMS
  products vary widely. This may be overcome as
  vendors conform to the new ODMG (Object Data
  Management Group) standard.
• Extended initial design issues. Classes,
  including inheritance, encapsulation and mapping
  issues plus all methods applicable to each class.
  
• No standard Object Manipulation Language. Instead
  object manipulation is performed by the language
  the DB is bound to.

15
Advantages/Disadvantages of OODBMS

• Disadvantages (contd)
• Lack of system catalog standards.
• Lack of view definitions - will be overcome with
  newer, improved products.
• Poor support for ad-hoc queries. The DB is
  designed to be navigated in a particular way.
• Lack of declarative integrity constraints.
• Foreign key support is built into the methods or
  procedural code. There is no equivalent to ON
  DELETE RESTRICT or ON UPDATE CASCADE, etc.
• Possible database corruption - some OODBMS run is
  the application process space to improve
  performance. Wild pointers from the application
  program may overwrite and corrupt data.

16
Some OODB Approaches

• OOPS ExtensionDB support is added to a
  programming language. e.g.
• ONTOS (C)
• ObjectStore (C)
• GemStone (Smalltalk, Opal, C)
• RDBMS ExtensionOO support is added to a
  relational database, ie. Object-Relational DBMS.
  e.g.
• POSTGRES (University INGRES, QUEL)
• Starburst (IBM research)
• IRIS (OSQL, SQL)
• New OODBMSFully OODBMS. Only stores data in the
  form of objects, so does not support tuples.
  Performance is optimized for fast access of
  objects from the server and transparent access of
  objects from the client side. e.g.
• ORION (Common LISP)
• O2 (C, CO2)

17
Object Database Standards

• Initiatives
• Object Database Management Group ODMG-93 1.0,
  the ODB Standard.
• ANSI X3H7 and X3T5.4 Standards prototypes.
• If and when these groups get together, we may
  have a true standard.
• ODMG-93 1.0 'StandardSpecifies
• object data model (ODM)
• object definition language (ODL)
• Object Interchange format (OIF)
• object query language (OQL)
• bindings to languages, such as C, Smalltalk and
  Java
• Future Common Object Request Broker Architecture
  (CORBA) for DDB

18
Object-Relational Databases

• Extended relational and object relational are
  synonyms for database management products that
  try to unify aspects of both the relational and
  object databases. (Note There is no official
  definition of what an object relational database
  management system is.) Won Kim, founder of
  UniSQL, recently published a white paper
  describing a framework with which to evaluate the
  completeness of a product's compliance with seven
  major categories of capabilities of object
  relational databases.
• Read the article Object Database vs.
  Object-Relational Databases by Steve McClure
  for details.IDC Bulletin 14821E - August 1997
  (http//www.cai.com/products/jasmine/analyst/idc/1
  4821Eat.htm)

19
Nested Relational Model

• A drawback of relational model is that it can
  represent data only in the simple first normal
  form. There are two proposals to improve it.
• Since the concept of dependencies has been
  proposed to eliminate information loss
  accompanying updating, databases without updating
  such as those used only for searching do not have
  to be in the first normal form.
• Decompositions of relations according to
  multi-valued dependencies are not always
  necessary in order to prevent errors in updating.
  

20
Nested Relational Model

• The first idea was developed in the fields of
  information searching and so on. And the second
  one was proposed in 1977.
• Each value in the model can be a set or a
  hierarchical structure. There are two advantages,
  i.e., the expressions of data in the model are
  natural or efficient and less join operations are
  necessary, which means data processing becomes
  generally faster.
• In the beginning the model was called the
  non-first-normal-form(NF ) relation and so on,
  but calling it the nested relation was agreed
  upon internationally in 1986. However, the
  insistence that the nested relation and the
  unnormalized relation should be distinguished
  still exists.

21
SQL 3 Standard

• Read Why We Need SQL3? by By John E. Seytabla
  (http//www2-iiuf.unifr.ch/ds/courses/db/pdf/whys
  ql3.htm)