Object Relational Databases


Some good additional notes on the subject can be found at:



One point of view is to understand them as extensions of relational databases.
  (Therefore called Object-Relational databases or O-R systems)


Object technology is of great interest because it promises to help solve
problems.  Expectations include:


improved software quality, reliability, testability, and extensibility
shorter development times  greater reusability of code.


Mgrs and programmers expect easier application maintenance and improved
ability to deal with increasingly complex applicaitons (often including
multi-media or media-rich applics with voice, video, image and text).

      
Why is OO technology given high hopes?


One reason is that objects are developed in a well-modularized fashion (modular
code is a common in top-down development and modular or hierarchical data is
common in most data models (data hierarchies eg, database, files,
records, fields) but OO combines the two modularizations.


This modularization helps localize changes & results in small managable building blocks (objects).
These objects can be composed to combine functionality, specialized to deliver new functionality


BASIC OBJECT TECHNOLOGY PRINCIPLES:

Modularization - Develop and write in small understandable modules of data
structures and operations allowable on those data.


Encapsulation - distinguish between interfaces (describe WHAT object does)
     and implementation (HOW object does it).

Typing - group all objects having same interfaces (characteristics) and treat as same "type".

Inheritance - reuse what's been done, define new types with characteristics of
   already defined type + some additional characteristicss.  The newly defined
   type inherits the shared characteristics from the already-defined types.


Messaging - Ask object to perform one of its fctns by sending message (phrased
in simple standard way) independent of how/where object is implemented.


Polymorphism - use meaningful names of operations.  The system will figure out
at runtime exactly which operation code to invoke based on type of object that
receives message (late binding).  Different kinds of objects can respond
to same message (message overloading).  (eg, DISPLAY message can be received by
person, photo, graph, video objects).



Object is a software building block.  Each object has a data structure and
performs a set of actions or operations, whose implementation need not be known.


Objects need be aware of each others interfaces only.


Object model provides representation of real-world entities, with their behavior and interactions.


Well architected object environments enable objects to use each other's
services (even if developed independently).


Software interoperability in heterogeneous, distributed computing
environments is the objective of standards like the CORBA (Common Object
Request Broker Architecture) from the Object Mgmt Group (OMB) (vendors...).
CORBA includes Interface Def Lang (IDL), a respository making def'n available,
message brokering services (deliver interobject requests).


With respect to terminology, some approaches extend and integrate
data models (ER model for instance) process models (structure charts, DFDs)
state models (Petri nets).  Others introduce entirely new terms.



Object solutions involve multple, overlapping technologies:


Graphical User Interface (GUI) is an object oriented interface (extensible
set of user-interaction capabilities, built on a model of well-defined ops,
that are invoked in a particular context) Eg, Mac, Windows..  opening a file, makes
applics on that file immeidately available.


Object-Oriented Programming Language (OOPL) used to code modules (objects)
that interact via a message protocol.  Often includes a class library of
extensible and refinable modules.  (C++, Smalltalk, OOCOBOL, Eiffel,
Objective-C, CLOS, Actor, Object-Pascal)


Object database management provides persistence for objects reather then for tables or records.
Object Operating Systems use a model of objects internally (eg, NeXTStep, Taligent, OS/400).



CLASSICAL SOFTWARE DEVELOPMENT

        .- - - .           . - .
       /   ||   \         / ||  \
      /    ||    v       /  ||   v
Analysis   ||   Programming ||  DB Def &
Design     ||               ||  Access
(ER Diags, || (C, COBOL,    ||  Normal,
SAD Charts.|| C++,Smalltalk ||  Views,
 DFDs)     ||               ||  SQL

At each stage we "vault" the fence in terms of models, languages, operations.
(eg, cursor mgmt for solving the set-at-a-time record-at-a-time mismatch)


Each time we vault the wall, there are significant barriers to overcome.
Models, terms, languages must be translated.  This requires work,
consumes resources, introduces errors and gets us farther from real-world.


The classical "waterfall development lifecycle:
Gather ---.
req'ments |
          V
     Analyze---.
     Req'ments |
               V
          Design----.
          Solution  | 
                    V
           Code Solution--.
                          V
                   Test Code--.
                              V
                       Integrate--.
                       and Test   |
                                  V
                              Maintain

together with vaulting of model walls has caused the software crisis of today.

CASE attempt to address software crisis:
Object technology tears down the walls
 - single unified conceptual model
 - improved productivity (no mismatch)
 - no model/lang translation erros

No-VAULT approach to software dev'ment:

  .--.   .--.  .--.   .--.   .--.   .--.   
  |__| .-|__|  |__| .-|__|   |__| .-|__|    
   |   |  @     |   |  @      |   |  @   
   ^   |  |     ^   |  |      ^   |  |    
  / \  |  |    / \  |  |     / \  |  |   
.--. .-@. |  .--. .-@. |   .--. .-@. |  
|__| |__| |  |__| |__| |   |__| |__| | 
          |            |             |  
        .-@.         .-@.          .-@.     
        |__|         |__|          |__|

Analysis &     Programming   Database
Design                      Def & Access

Object Database = repository to store and manage "pickled" objects
(ones we want to keep for a while - beyond the life of the creator program).

Performance Objective of Object DBMS:

1. make speed of access to persistent objects already in memory close to
speed of prog lang access to its own memory objects,

2. minimize network traffic by caching objects in prog memory and transferring
aggregates in 1 server access (guiding principle is to transfer requested objs
together w/o transferring other objs),

3. OODBMS tries to minimize disk traffic by clustering related objects on disk.o
Over-riding issue is distrib of objects on persistent storage (disk).


Ways Prog Lang Objects made Persistent:

1. use file system directly (eg, C++ library utilities).  Programmer must
"flatten" obj to fit flat file structure and "unflatten" later (change ptrs to ?,
Change ? to ptrs). Not sharable!

2. Object stored persistently in RDBMS.  (tempting if org uses RDBMS already).
Like file-system approach, but harder (since allowed only simple flat files
of records - record structure must be introduced also).

3. Object Relational DBMS (ORDBMS) which augment RDBMS structure to
accommodate objects (hide translation in DBMS).