Re: Semantic network DBMS [was: Re: Contexts (was Classes vs. Instances)]

["Rich Cooper" <rcooper15@comcast.net>]

I was consulting for IBM/GSD in the late seventies, and I remember one
speaker saying "we don't eat our own babies" as a rationale for why some
product didn't get offered.  In fact, IBM was a hardware company for so
many years that I'm surprised they ever started offering software (other
than that ugh "operating system" they proffered).  Sad.

Rich

> This is an easy one, and nothing so technically interesting as you 
> suggest.
> The early version of this DBMS was created during the time IBM had a "one
> database" policy, and that one database was IMS.  After years of struggle,
> the relational version of DBMS technology broke through the one database
> policy, and hence was dubbed "DB2."  There was no way there was going to 
> be
> a DB3, in spite of the best efforts of some very passionate people.  In
> fact the guy who demonstrated 60-times performance improvement in the
> Repository Manager test cases (yes this does go back a ways!) was 
> banished,
> and a short time later left the company.
>
> The technology was later licensed to Britton Lee (who brought you one of
> the first relational implementations on a dedicated database machine).  By
> then the principals in this endeavor, Dave Britton and Geoffrey Lee, had
> become allergic to venture capital, and the road to commercialization
> proved too rocky and steep for a self-funded venture.  History.
>
>
> Doug McDavid
>
> Business Transformation Architect
> IBM Academy of Technology - http://www-306.ibm.com/ibm/academy/index.html
> mcdavid@us.ibm.com
> 408-927-1565 (IBM tie-line: 457)
>
>
>
>             "Rich Cooper"
>             <rcooper15@comcas
>             t.net>                                                     To
>                                       Douglas McDavid/Boulder/IBM@IBMUS
>             05/07/2006 10:09                                           cc
>             AM                        "'Alan Ruttenberg'"
>                                       <alanruttenberg@gmail.com>, "Avril
>                                       Styrman"
>                                       <Avril.Styrman@helsinki.fi>,
>                                       <bniemann@COX.NET>, "Cory Casanave"
>                                       <cbc@enterprisecomponent.com>,
>                                       <cg@CS.UAH.EDU>, "Nigam Shah"
>                                       <nigam@psu.edu>, "'Paul Prueitt'"
>                                       <psp@virtualTaos.net>, "'Paul J.
>                                       Werbos'" <pwerbos@nsf.gov>, "Rolf
>                                       Schwitter" <rolfs@ics.mq.edu.au>,
>                                       "John F. Sowa" <sowa@BESTWEB.NET>,
>                                       <standard-upper-ontology@ieee.org>,
>                                       <standard-upper-ontology@listserv.i
>                                       eee.org>, "Susan Turnbull"
>                                       <susan.turnbull@gsa.gov>
>                                                                   Subject
>                                       Re: Semantic network DBMS [was: Re:
>                                       Contexts (was Classes vs.
>                                       Instances)]
>
>
>
>
>
>
>
>
>
>
> Hi Douglas,
>
> Why wasn't the IBM software released as a product?  It would be 
> interesting
> to know the rationale behind it.
>
> One surprising thing about DBMSs is the way performance varies with size.
> The winner on very large databases is nearly always Oracle, which has a
> tremendous amount of optimization.  The loser on very small databases is
> also nearly always Oracle because that tremendous amount of optimization
> is expended on every query.  Something like that might be behind the IBM
> product's nonrelease.
>
> -Rich
>
> Douglas McDavid wrote:
>
>> Rich --
>>
>> In response to:
>> "However, I have seen good papers about the functional data model (FDM)
>> method of database representation where all the concepts are nodes and
> all
>> the relationships are arcs between pairs of nodes, and every relationship
>> has an inverse.  It is very simple to construct an FDM with partial
>> knowledge of the application requirements, and change it quickly, as
>> compared to the usual SQL method.  The only problem yet to be solved is
>> that FDMs are hugely inefficient when represented in that simple way."
>>
>> Back in the late '80's I had access to an IBM dbms that was never
>> productized.  This was before I joined IBM, and was approached as a
>> potential customer.  This dbms was organized as the FDM you described.
>> This dbms had the advantages of extreme flexibility, and was lightning
>> fast
>> on retrieval.  A key design decision was to separate the data from the
>> pattern-processing language that manipulated the data.  I put all this in
>> the past tense, unfortunately, as a Betamax-like footnote to the history
>> of
>> technology.
>>
>> By the way, one representation method like your FDM is NIAM (ORM).  I
>> think
>> I'm dating myself here!
>>
>>
>> Doug McDavid
>>
>> Business Transformation Architect
>> IBM Academy of Technology - http://www-306.ibm.com/ibm/academy/index.html
>> mcdavid@us.ibm.com
>> 408-927-1565 (IBM tie-line: 457)
>>
>>
>>
>>             "Rich Cooper"
>>             <rcooper15@comcas
>>             t.net>                                                     To
>>             Sent by:                  "Avril Styrman"
>>             standard-upper-on         <Avril.Styrman@helsinki.fi>
>>             tology@ieee.org                                            cc
>>                                       "John F. Sowa" <sowa@BESTWEB.NET>,
>>                                       "Rolf Schwitter"
>>             05/03/2006 07:53          <rolfs@ics.mq.edu.au>,
>>             PM                        <standard-upper-ontology@listserv.i
>>                                       eee.org>, <cg@CS.UAH.EDU>, "Nigam
>>                                       Shah" <nigam@psu.edu>, "'Paul
>>                                       Prueitt'" <psp@virtualTaos.net>,
>>                                       "'Alan Ruttenberg'"
>>                                       <alanruttenberg@gmail.com>, "'Paul
>>                                       J. Werbos'" <pwerbos@nsf.gov>,
>>                                       <bniemann@COX.NET>, "Susan
>>                                       Turnbull" <susan.turnbull@gsa.gov>,
>>                                       "Cory Casanave"
>>                                       <cbc@enterprisecomponent.com>
>>                                                                   Subject
>>                                       Re: Contexts (was Classes vs.
>>                                       Instances)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Avril Styrman wrote:
>>
>>> Rich,
>>>
>>> even though views could be used to define types, the object-oriented
>>> way of doing this with an editor would be much quicker. It is just
>>> easier to press plus-button and give a name for the sub-table and
>>> add a couple of slots for it than to create views and to explicitly
>>> define relations of the views, and to join columns of tables. Perhaps
>>> I just haven't confronted an SQL editor with which this can be done
>>> as easily as with a basic ontology editor.
>>
>> Nor have I;  SQL databases are surprisingly short of good design tools
>> so far as I've seen.  There are tools out there, but very few people seem
>> to use them, and they're not all that good.
>>
>>
>>>> So what exactly could be added to SQL to make types any more useful
>>>> there than the standard tables, views and procedures?
>>>
>>> If views were used to define types, there should be a detailed
>>> convention of how to use the views specifically for that task. If
>>> views were used in type definition, views could not be used in
>>> anything else. Maybe there are so many ways of using the views (?) that
>>> a convention could no be reached. In this case, another feature should
>>> be added to SQL: the reserved subTableOf property for all the tables.
>>> Only automatical functionality would be added to SQL editors: a
>>> subtable collects all the columns of its supertables. There would not
>>> be problems with stacks that you mentioned if SQL would remain
>>> othervise the same.
>>
>> It would be relatively simple to develop a tool that helps you create
>> objects.
>> Whether the objects are implemented as views, tables or procedures seems
>> to
>> me to be independent of the object level.
>>
>> When C++ first came out, it was implemented as a precompiler which
>> translated
>> C++ into C.  A similar approach could translate SQL++ into SQL.  The only
>> loss with this scheme is reverse engineering; you might not be able to
>> translate
>> SQL into SQL++ without a huge amount of semantic discovery.
>>
>>> Think how many hours the IT society would win if SQL databases
>>> were planned in an object-oriented fashion.
>>
>> The main problem in the application of SQL to real world problems is not
>> at
>> the design stage, when pretty simple structures are envisioned;  its much
>> later
>> as the whole thing starts to look like a ramshackle database because the
>> requirements change so much faster than the database can be reorganized.
>>
>> Practically every programmer who uses SQL databases today is very
> familiar
>> with the object-oriented approach to programming languages.  I feel
> pretty
>> strongly that the way SQL provides persistent storage makes the
>> object-oriented
>> approch much less useful in that representation.  But give me
>> object-oriented
>> programming languages over the old kind any day.
>>
>> However, I have seen good papers about the functional data model (FDM)
>> method of database representation where all the concepts are nodes and
> all
>> the relationships are arcs between pairs of nodes, and every relationship
>> has
>> an inverse.  It is very simple to construct an FDM with partial knowledge
>> of
>> the application requirements, and change it quickly, as compared to the
>> usual
>> SQL method.  The only problem yet to be solved is that FDMs are hugely
>> inefficient when represented in that simple way.  SQL brings a very large
>> degree of optimization because it only has tables, views, procedures and
>> domains.  Adding more constructs to SQL would make optimization a bit
>> more difficult, but if a good case could be made that the new constructs
>> make
>> SQL databases easier to reorganize quickly, that would be a good selling
>> point.
>>
>> JMHO,
>> Rich
>>
>>> Avril
>>>
>>>
>>> Quoting Rich Cooper <rcooper15@comcast.net>:
>>>> Any frame can be implemented as a view, perhaps of multiple tables.  To
>>>> use
>>>> multiple types (classes) in a frame, simply combine the tables with the
>>>> proper
>>>> join expressions and zot - you have a frame.
>>>>
>>>> When the industry found out that relational SQL databases were so
>>>> useful,
>>>> people naturally jumped to the conclusion that object-oriented
> databases
>>>>
>>>> could
>>>> go yet one better by adding types of a higher level of abstraction.  As
>>>> you
>>>> may
>>>> have noticed, it didn't work.  That's because object-oriented programs
>>>> use
>>>> stacks
>>>> to keep the objects straight, but persistent storage systems like SQL
>>>> don't
>>>> have
>>>> any use for stacks, except in stored procedures, where they are dynamic
>>>> data
>>>> structures, not persistent tables.
>>>>
>>>> So what exactly could be added to SQL to make types any more useful
>>>> there
>>>> than the standard tables, views and procedures?
>>>>
>>>> IMHO, SQL has reached its major advances already.  More built in
>>>> functions,
>>>> a little improvement in domains (blobs should already have been
>>>> supplemented
>>>> with JPEGS, files, even databases as domains, but for some reason this
>>>> hasn't
>>>> happened yet).
>>>>
>>>> If anyone can suggest an improvement to SQL in detail, I would be very
>>>> receptive.
>>>>
>>>> Rich
>>>
>>
>>
>>
>