Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!prodnet.la.locus.com!jfr
From: jfr@locus.com (Jon Rosen)
Newsgroups: comp.databases
Subject: Re: Ingres Object Management Extension
Keywords: Ingres, Object Management Extension
Message-ID: <20979@oolong.la.locus.com>
Date: 4 Jan 91 03:13:43 GMT
References: <1991Jan3.021150.12498@bhpmrl.oz.au>
Organization: Locus Computing Corp, Los Angeles
Lines: 115

In article <1991Jan3.021150.12498@bhpmrl.oz.au> cpl@bhpmrl.oz.au (Paul Lloyd) writes:
>A query to Ingres users, and any others who may have wishful thoughts along
>these lines:
>
>Could you please tell me what you are using IngresU Object Management Extension
>for?  Its aim is to extend the available data types beyond the standard ones
>supported by SQL, and to allow the database developer to define operators
>appropriate to that data type which can be used directly in an SQL query (this
>is also extended to redefining standard SQL operators for that data type).  It
>is considerably more than SybaseUs data types which are more a way of 
>specifying domains (eg. telephone numbers, product code numbers, etc.), and are
>therefore more data classes with associated edit masks.
>
>It seems to me that this has distinct potential in technological areas, but
>my imagination is limited, and technology is such a vast area.  I guess I am
>looking for some generally applicable ideas which I can sell to my clients who
>look on databases as something for the accountants, or as something on which 
>to conduct subject and literature searches.  Is the Object Management Extension
>an idea whose time is yet to come?  I havenUt come across any articles showing
>how it can be used, yet.
>
>Your help will be greatly appreciated.
>--

The object extensions to Ingres were based on the Postgres studies
done at Berkley.  Micheal Stonebraker, who was a founder of Ingres
Corp (formerly RTI, now Ask Systems), was a principal in the research.
I heard Stonebraker talk at the dbExpo last year in San Francisco and
his discussion of object extensions to SQL intrigued me very much.
 
He contents that SQL has won as the data access language of choice 
and that future object-orientation in data bases will be through
SQL extensions or new ANSI standards for SQL which support the
three major aspects of objects for data bases: user-defined
data types, user-defined operators and user-defined accelerators.
Inheritance comes with user-defined data types.  
 
The example he gave was excellent.  A typical real-world application
might involve building a data base as a backend for a 3d graphics
product.  You might want to store all of the different things in
a building, for instance, such as tables, chairs, doors, windows,
etc., so that you could use your graphics frontend product to
"walk" through the building.  At each stage of the viewing
process, the product needs to find all objects within your
viewport and create the 3d images from the data base.
 
To simplify the request (and to show how inadequate current
SQL is at this type of problem), he assumed that we would
only deal with 2 dimensions and further, that we were only
interested in boxes (not complex 3d objects like tables).
 
A table to hold a set of rectangular boxes would look like
this in normal SQL:
 
  Create Table BoxTable
  ( BoxId      Integer,
    X1         Float,
    Y1         Float,
    X2         Float,
    Y2         Float)
 
where (x1,y1) and (x2,y2) were the upper left and lower right
coordinates of the box.
 
To answer the query "Find all boxes that are within the viewport
bounded by (0,0)-(1,1)" you need to give the following SQL:
 
Select BoxId Where X1 > 0 And X1 < 1 And Y1 > 0 And Y1 < 1
                Or X2 > 0 And X2 < 1 And Y2 > 0 And Y2 < 1
                Or ...  

You can see where this is going... And this is a simple 2d box
query... Imagine trying to do this with a 3d complex object...
 
What we really need is a data representation for a box...
 
  Create Table BoxTable
  ( BoxId      Integer,
    Box        BoxType)
 
Now, the internal representation of a BoxType object is defined
somewhere else... It maybe the two vertices or maybe it is 
something else (origin, height and length, etc.)  Now what
we want to say is:
 
Select BoxId Where Intersect(Box,BoxType(0,0,1,1)) = True
 
or some similar syntax... BoxType(...) is used as a constructor
to create a new temporary object of type box from a set of
data values and Intersect is a Box-related operator which
returns whether Box and BoxType intersect (True or False)...
 
Of course, this might just be a comparison similar to the one
we did manually, but at least the semantics have been hidden...
better, we would have a different type of indexing scheme,
such as an R-tree, which would be a box-related accelerator
that would be used by the relational data base and would allow
much faster comparisons and searches using BoxType objects.
 
Anyway, this is a quicky intro on object extensions... 
I see a lot of commercial uses... For one, simple types
of objects that are used a lot can be defined once and
used in lots of tables without taking up programmer time
to define (let alone keep in sync)... If I was building
a commercial application, for instance, I might define
an Address type which consisted of StreetAddr, City, State,
Zip and use the Address type in all of my tables... This
is more consistent and easier to reuse...  Plus, if I
decide to build some special functions or algorithms
for searching, formatting, or ???, the addresses, I can
create user-defined operators and let everyone use them.;
 
Hope this long-winded discussion has been of SOME benefit.
 
Jon Rosen