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@...
> 408-927-1565 (IBM tie-line: 457)
>
>
>
> "Rich Cooper"
> <rcooper15 <at> comcas
> t.net> To
> Sent by: "Avril Styrman"
> standard-upper-on <Avril.Styrman@...>
> tology@... cc
> "John F. Sowa" <sowa@...>,
> "Rolf Schwitter"
> 05/03/2006 07:53 <rolfs@...>,
> PM <standard-upper-ontology <at> listserv.i
> eee.org>, <cg@...>, "Nigam
> Shah" <nigam@...>, "'Paul
> Prueitt'" <psp@...>,
> "'Alan Ruttenberg'"
> <alanruttenberg@...>, "'Paul
> J. Werbos'" <pwerbos@...>,
> <bniemann@...>, "Susan
> Turnbull" <susan.turnbull@...>,
> "Cory Casanave"
> <cbc@...>
> 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@...>:
>>> 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
>>
>
>
>
========================
To post a message, send mail to cg@...
To unsubscribe, send mail to majordomo@... with the command
'unsubscribe cg' in the message body.
See http://news.gmane.org/gmane.comp.ai.conceptual-graphs for the mailing list archive.
See http://conceptualgraphs.org for the Conceptual Graph Home Page.
For help or administrative assistance, mail to owner-cg@...
RSS Feed