Re: Interesting article: In the Beginning: An RDBMS history

From: paul c <toledobythesea_at_oohay.ac>
Date: Mon, 03 Apr 2006 16:12:13 GMT
Message-ID: <xPbYf.218029$B94.60669@pd7tw3no>

x wrote:
> "paul c" <toledobythesea_at_oohay.ac> wrote in message
> news:GX_Wf.201803$sa3.143853_at_pd7tw1no...
>
>

>>Also read somewhere that nowhere does it mention 'relations'.  Is
>>anybody able to confirm this?

>
> I don't know about the standard but the working drafts are full of
> "relationships" :-)
>
>

>>>5WD-02-Foundation-2003-09:

>
>
> a)4.14.4 *Relationships* between tables
>
> b)The next Subclauses recursively define the notion of known *functional
> dependency*. This is a ternary *relationship* between a table and two sets
> of columns of that table. This relationship expresses that a functional
> dependency in the table is known to the SQL-implementation.
>
> c)24.3 Implied feature *relationships* of SQL/Foundation
>
> d) 670 The following Language Opportunity has been noted:
> Severity: Minor Technical
>
> Reference: P11, SQL/Schemata, Clause 5, "Information Schema"
>
> Note at: None.
>
> Source: DBL:LGW-152/X3H2-97-352 (also DBL:LGW-023/X3H2-97-044, SEQ# 409,
> USA-105)
>
> Many "information discovery" products depend upon full text searches of
> document databases
>
> to feed the indexing mechanisms used in their search engines. It is very
> difficult to extend
>
> this technique to "structured" *relational* databases especially if ...
>
>
>
>

>>>5WD-01-Framework-2003-09:

>
>
> In other cases, certain SQL objects cannot exist unless some other SQL
> object exists, even though there is no
>
> inclusion *relationship*. For example, SQL does not permit an assertion to
> exist if some table referenced by the
>
> assertion does not exist.
>
>
>

>>>5WD-11-Schemata-2003-09:

>
> The DIRECT_SUPERTABLES base table contains one row for each direct
> subtable-supertable *relationship*.
>
> The DIRECT_SUPERTYPES base table contains one row for each direct
> subtype-supertype *relationship*.
>
>

>>>5WD-10-OLB-2003-09:

>
>
> JDBC provides a complete, low-level SQL interface from Java to *relational*
> databases.
>
>

>>>5WD-14-XML-2003-09:

>
>
> XML elements are a kind of types. Tables as specified in this paper in the
> *relational* world are
>
> mapped to these elements and do not have a named type in the *relational*
> domain. We are of
>
> the opinion that this should be preserved in the mapping and lead to
> anonymous complex types
>
> in the generated XML Schema.
>
>

Thanks for that, anyway. Maybe I was dreaming about what I thought I read. I see the word 'relation' doesn't appear in the quotes but maybe this doesn't matter (assuming that those drafts' other words appear in the actual standard with the same intended meanings).

Codd, in his 1970 paper, pg 80, said: "Accordingly, we propose that users deal, not with relations which are domain-ordered, but with relationships which are their domain-unordered counterparts". In the next paragraph he says: "To sum up, it is proposed that most users should interact with a relational model of the data consisting of a collection of time-varying relationships (rather than relations".

It seems that by using the word "relationship" he was merely trying to draw a line between mathematical relations that have ordered domains and ones that replace the ordering with names as well as between logical and physical representations. (By "most users" in the second sentence I'm guessing that he was talking about everybody except DBA's.) Also seems that what he meant by 'relationship' was roughly what we call 'relation' today.

So I guess it would be reasonable for the standard to use "relationship" as long as it clarifies where it uses that word in some special sense, such as when talking about functional dependencies which seems to me to   throw 'relationship', 'table' and 'columns' up in the air and let them land on the floor however they may. That heading 4.14.4 about "Relationships between tables" seems murky since Codd's 1970 paper AFAICT mentions tables only in the sense of 'data description tables' (presumably in the dictionaries of the hierarchical products of those times, the 1969 paper doesn't seem to mention them at all). Either that or define such terms at the beginning - maybe it does, I'm too cheap to buy it.

p Received on Mon Apr 03 2006 - 11:12:13 CDT