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 matter of changing the
references in pg_inherits from pg_class.oid to pg_type.oid? Or
would this cause major breakages in other parts of the code?
* The existing "CREATE TABLE tablename AS" syntax is incompatible
(or needs to be modified to comply) with the SQL99 syntax of
"CREATE TABLE tablename AS typename";
* Code for creating a composite attribute member currently
implements them as a oid referencing a seperate table. According
to Date this is probably "not a Good Thing" (see [DAT00] Section
25.2 pg 865) - in this case relvar = object class rather than his
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 currently handled. 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 aware of!

For the moment I guess I don't need to worry about the parser, just
how the operations related to the 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(at)uow(dot)edu(dot)au

uproot your questions from their ground and the dangling roots will be
seen. more questions!
-mentat zensufi

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