From: Michael M. Gorman [mmgorman@wiscorp.com]

Sent: Friday, September 03, 1999 9:00 AM

To: Richard T. Dué

Subject: If I don't think it's a spotted owl then I can cut down the

tree.....

 

Richard:

 

I just read your Millenium Rules paper that was posted by Jeff

Sutherland.... Very interesting..... As you might have gathered from the

subject line, I have some level of disagreement......

 

First, though, let me state my biases..... First I'm a data bigot.....Have

been since 1969..... I also believe that for any given set of business

policy there is one and only one correct data model. That is, entities,

attributes, AND relationships..... To me, verbs (processes) are just nice

little connecting words between subject (noun) and object (noun)......

 

Of course, I may be stating the above to a slight extreme.......

 

~~~~~~~~~~~~~~~~~~~~~~~~~~`

When ANSI H2 started to do "objects" in SQL (that was around 1991), it

became very clear to me that we in H2 (I've been it's secretary since 1978)

didn't have a firm statement of the "business problem" that was to be

solved. In general, Codd's work on the relational data model form the early

1970s served as the business problem to be solved for SQL 1986, 1989, and

1992. Since we didn't know that we had one, we sort of didn't know that we

needed one for "database" objects. I clearly distinguish between "database"

objects and other kinds of objects, e.g., "process" objects.

 

We thrashed around for several years and finally arrived at what we have

(SQL 1999). While we may have done a reasonably good job of having nested

structures of data within columns of tables and the ability to attach

methods to those nested structure components, I don't think we achieved

what SHOULD have been achieved with respect to objects......

 

Your paper brings up a good set of points.... Primarily that an object

class contains many different object states. And, I believe that for any

well-behaved business, these object states are well defined and in general

exist along a business life cycle.......

 

So, my quest for SQL 200x is to have database object classes which contain

the following characteristics:

 

1. They are defined entirely within the language SQL

 

2. They are defined across multiple tables such that some tables can:

      a) only belong to one and only one object class

      b) some are owned by one object class for the purpose of update and

delete, and are viewable by

            other object classes

 

3. The objects within an object class are represented a well defined set of

states that exist on a continuum.

 

I believe that these three main characteristics closely track what you said

except that I believe that there are a fundamental set of relationships

among tables within an object class that is non-variant. An object  from

within the object class is essentially the materialization of the data from

a set object class tables that meets a set of business-defined rules. Each

set of rule thus defines an object state.

 

Regards,

Mike Gorman

 

P.S.

We're going to have an ANSI H2 meeting in Banff in February 2000..... So,

maybe we can continue this discussion then......

 

 

 

==============================================

Whitemarsh Information Systems Corporation provides consulting

services, books, courses, workshops, training, and methodologies

for information resources planning and management, and a full

range of specialized data management architecture and database

design services.

==============================================

Michael M. Gorman

Whitemarsh Information Systems Corporation

2008 Althea Lane

Bowie, Maryland 20716-1518

USA

Phone: +1.301.249.1142

FAX: +1.301.249.8955

Email: mmgorman@wiscorp.com

WWWeb: <http://www.wiscorp.com/>

==============================================