Re: Is there a "third generation" DB yet?

Scottie:

> Specifically a 3rd generation DBS had to:
>
> 1) Support object and relational operations including
> inheritance and "Multiple inheritances are essential"
> thus the constructed DBs inheritance hierarchy would
> be directed graphs
This first criteria is meaningless until a *FORMAL* theory and definition of `object' is established. It should be noted that the XML abstract mentions `Graph Theory' but deviates from it considerably, thus making XML a poor candidate to `uplift' for compliance with this challenge. There currently is no XMLDBMS because there currently is no *FORMAL* and rigorous XML data and data management model.
A truely relational DBMS would meet this point, provided we had an `object' model, and it should be noted The Third Manifesto (Date, Darwen) does indeed attempt to address inheritence which is one of many foundations currently being explored for the required *FORMAL* definition and model of `object'.

> 2) Provide additional type constructors e.g.:
> a) an abstract data type system to construct new base types
> b) an array type constructor
> c) a sequence type constructor
> d) a record type constructor
> e) a set type constructor
> f) functions as a type
> g) a union type constructor
> h) recursive composition of the above constructors
This looks to me like some marketer's bozotic check-list. The first point IMPLIES `a set type constructor' since a relation is a subset containing the cartesian products of one or more attribute sets. The very existence of a relation *REQUIRES* `a set type constructor'.
Granted the *FORMAL* definition of a relation then a tuple is a `record type generator'. Even SQLDBMS's have this much support. Is `functions as a type' meant to be `Y = λf·((λx·f(x x))(λx·f(x x)))'? Or is `functions as a type' meant to be `void foo(int x) { // code here }'?
I doubt the author knows what `a union type constructor'. The final subpoint, `recursive composition of the above constructors', is vague. Does the author demand tail-recursion, or simple-recursion? The former would be required for the existence of functions (as a type) of the form `Y = λf·((λx·f(x x))(λx·f(x x)))'.

> 3) Allow rules, functions and operations to be
> implement in a 4GL

This is a vacuous statement.

> 4) Must subsume second generation DBS abilities:
> a) Non procedural query language with query optimizer
> b) Provide a rules system
> c) Full SQL client/server support
> d) Support for views
Most products today have a constraint system, but all SQLDBMS systems I am aware of require procedural constraints to supplement their limited declaritive constraint capability. Only an RDBMS would provide a rule system via declaritive constraints universally. By `Support for views' does the author mean for SELECT only, or any operation? SQLDBMS systems currently support SELECT, and Alphora's product provides for INSERT, UPDATE, and DELETE operations also. If the author means for `SELECT and only SELECT' then Alphora's product is not in compliance. If the author means `At least support SELECT' then all SQLDBMS and RDBMS products are in compliance. If the author means `support SELECT, UPDATE, INSERT, and DELETE' then only an RDBMS would be in compliance.

> 5) Must undo any hard coded requirement for UIDs
> and discourage navigation

I do not know what the author could possibly mean by this.

> 6) Must provide support for 4GLs

I am confused. The author repeats himself from point #3.

> 7) Must support distributed databases, and
What does the author mean by `support'?

> 8) Must (essentially) automatically tune the system to
> perform efficient data management
The Relational Model *requires* a logical/physical distinction, which places this outside the scope of DBMS and entirely onto specific product vendors. That being as it may, it should be regarded as a Good Thing, and any vendor implementing such a mechanism would no doubt be greeted with great acceptance.

> The questions are:
>
> 1) Do you agree that the above list accurately describes the requirements
> for a true 3rd generation database? (if not what is missing or what is
> incorrect?)
I would suggest the author tries to learn at least the fundamentals of the area he is researching before making a `shopping list'.

> 2) Is there a current database system that meets these requirements?
This question is bozotic. A *CORRECT* DBMS is *always* better than a *BROKEN* DBMS. I would suggest everyone examine Alphora's product, Dataphor (http://www.alphora.com/). This meets all requirements for a Truely Relational Database Management System, which is certainly better than any SQLDBMS.

> I am aware of the Hugh Darwen & Chris Date's 1995 paper "The Third
> Manifesto" which argues a number of the points above. But, I wanted to
> center the discussion on the original paper and move forward from there.
> Feel free to counter with your views between the two papers.
Usually it is easier to get forgiveness than permission, but it looks like I have both in this case!

`Third Generation' sounds more like `2/3 Assed', Timothy J. Bruce
uniblab_at_hotmail.com
</RANT> Received on Fri Apr 16 2004 - 01:19:51 CEST