Re: abstract data types?

Hi Josh, all,

Thanks for your comments. My 2c worth:

Josh Berkus wrote:

> Mr. Reid,
> 
> 
>> To answer your question, it is a bit hard to say at the moment as the
>> design  schema for our project has only just been started.  The draft
>> versions of  the ISO standard that I have seen use an object oriented
>> data model, so  to me it makes sense to try and keep the database schema
>> as close as possible to this (minimise data impedance).
>> 
>> Briefly, at its' simplest the schema will probably use a two tier approach.
> 
> <snip>
> 
> Let me preface this by saying that I know squat-all about building
> geometric databases.   My background is in db's for accounting, billing,
> scheduling, and fundraising.

Yes, definitely a very different beastie (as my aching head is proving). 
The more I learn about spatial information systems, the more I come to 
the conclusion that I know squat about them as well. As far as the 
relationship between the schemas for financial and spatial information 
systems goes, a book I have (on OO database management) goes so far as 
to say "that relational database systems do not adequately support these 
so-called non-standard applications."
From the research that I have done, by far the best DBMS for these 
applications is Informix. Funny about that, having Postgres in its' 
ancestory :-) Unfortunately I can't speak from personal experience - I 
don't have any access to it, as at uni we are a Oracle/MS SQL 
Server/mySQL shop, and from my preliminary investigations none of these 
seem to cut it for this task as far as I am concerned :-(

> Given that .., over the last 3 months, I have become a believer in C.J.
> Date and Fabian Pascal, who point out quite a few ways that
> object-oriented and relational approaches to data problems *cannot* be
> made to reconcile.  See http://www.firstsql.com/dbdebunk for some
> examples of their objections. 

Interesting. This is a really cool site. Thanks. However I don't see how 
you draw the conclusion from what I have read on this site "that 
object-oriented and relational approaches to data problems *cannot* be 
made to reconcile." C.J. Date here seems to be arguing more about the 
semantics employed in UML modelling, Pascal more about the quality of 
database design. This site does give me the urge to read up on set 
theory - I've forgotten what little I once knew.

In [DAT00] (Section 25.1 pg 863) Date states "we need do nothing to the 
relational model in order to achieve object functionality in relational 
systems - nothing, that is, except implement it, fully and properly, 
which most of today's systems have so signally failed to do."

He mentions in the prelude to that statement (in a discussion of the 
incorporation of "proper data type support into the relational model") 
that "object-orientation" involves:
  1. Proper data type support  2. Type inheritance (actually, he considers this as being part of 1.)     
He then states that "the support is already there [in the relational 
model -jgr], in the shape of domains (which we prefer to call types 
anyway)."

> Of course, Date and Pascal reject Object Oriented approaches entirely,
> something I'm not ready to do ... 

Hmmm, from what I've read I don't see it that way. My current 
understanding is that "we acknowledge the desirability of supporting 
certain features that are commonly regarded as aspects of object 
orientation. However, we believe that the features in question are 
orthogonal to (i.e. independent of) the relational model ..." ([DD00] 
Chapter 1, pg 6). Interesting, I just noticed the statement "is truly 
relational (unlike SQL)."!

> but I do see that trying to build a
> database accessable to both a range of OODB tools and relationally
> compliant is not achievable.

Sorry, disagree strongly here. My interest in PostgreSQL was sparked 
when I first came across a link to Postgres in a list of object-oriented 
databases. From a quick look at the docs (I think the ones I first 
looked at were for v6.5 or an even earlier version than that) I could 
see the potential for the enhanced data type support, that at the time I 
believed was essential for a GIS (or SIS) - or at least would be if the 
programmer's, or even more so the maintainer's, sanity was to be 
preserved. Actually, at the time I thought ADT style type support was 
already fully implemented. A little knowledge can be a dangerous thing, 
especially when mixed with a lack of sleep ;-)

As far as I can tell, PostgreSQL has most, if not all, of the building 
blocks to supply support for abstract data types already in place. 
Whoever thought up the system catalogs (as well) was one very smart 
individual. Salutations, whoever you are!

These are some of the potential problems for implementing abstract data 
types that I can see so far:
   * Inheritance is currently implemented at the relation level, rather      than the type level. Is this simply a
matterof changing the      references in pg_inherits from pg_class.oid to pg_type.oid? Or      would this cause major
breakagesin other parts of the code?   * The existing "CREATE TABLE tablename AS" syntax is incompatible      (or needs
tobe modified to comply) with the SQL99 syntax of      "CREATE TABLE tablename AS typename";   * Code for creating a
compositeattribute member currently      implements them as a oid referencing a seperate table. According      to Date
thisis probably "not a Good Thing" (see [DAT00] Section      25.2 pg 865) - in this case relvar = object class rather
thanhis      preferred domain = object class.     
 
I assume the methods necessary to read and write complex attributes 
would be similar in nature to those employed for table access - correct? 
Oh, well. Back to tracing how procedures are called from the system 
catalogs I guess. From a previous post of mine:
   "Can you please give me some pointers as to where I should look in    the docs and code to see how classes are
currentlyhandled. I'm    thinking specifically of:          * How (and where) the access methods for class tuples are
      implemented and called.       * Where the code for creating classes hides       * Anything else that I should be
awareof!            For the moment I guess I don't need to worry about the parser, just    how the operations related
tothe classes (both system and user)    work/are implemented. Correct?"
 

Any help people can give me would be much appreciated. I'm already 
feeling a little lost. I hope people don't mind if I ask a lot of dumb 
questions over the next few weeks :-) Is this the appropriate list, or 
should I move over to hackers?

Cheers,
John

Where I'm getting my info from:

Book [Dat00]

Author: Date, C.J.
Title: An Introduction to Database Systems
Publisher: Addison Wesley Longman
Date: 2000
Edition: 7th

Book [DD00]

Author: Date, C.J.; Darwen, Hugh
Title: Foundation for Future Database Systems : the Third Manifesto
Publisher: Addison Wesley
Date: 2000
Edition: 2nd

Book [SB99]

Author:    Stonebraker, Michael; Brown, Paul
Title:     Object-Relational DBMSs : Tracking the Next Great Wave
Publisher: Morgan Kaufmann
Date:      1999
Edition:   2nd


Book [For99]

Author:    Fortier, Paul
Title:     SQL3 Implementing the SQL Foundation Standard
Publisher: McGraw Hill
Date:      1999
----------------------------------------------------------------------
john reid                                  e-mail john_reid@uow.edu.au       
uproot your questions from their ground and the dangling roots will be
seen.  more questions!                                                      -mentat zensufi

apply standard disclaimers as desired...
----------------------------------------------------------------------