Re: Foreign superkey support

"Marshall" <marshall.spight_at_gmail.com> wrote in message news:1155100237.103860.180160_at_h48g2000cwc.googlegroups.com...

> In other words, there is a many-to-many relationship between
> constraints and relvars. (Or relations, if we are thinking in
> descriptive rather than prescriptive terms.) For example,
> we often speak of a foreign key constraint as belonging to
> one particular table, but it is equally a constraint on two tables.
> On one table it restricts inserts and on another table it restricts
> deletes. So we must necessarily classify it as a database
> constraint. But really, all constraints are all database constraints,
> although there may be some database constraints that only
> happen to be quantified over a single relvar.
>

Here I am as Johnny one note, chiming in again. One way to get a model of constraints is to look
at the system tables of some implementation, and derive a logical model by reverse engineering.

I'm going to suggest two places to look to get a model: one is the SQL standard system tables, which I'm not familiar with. I figure they ought to be worth looking at anyway.

The other is to look at the way system tables are implemented in DSRI. The easiest way to get a handle on the DSRI system tables is probably via Interbase/Firebird. Jim Starkey used pretty much the DSRI model when he started building Interbase. I conclude this without having studied Interbase much. What I did study a little was Sybase Data Architect's internal model of the Interbase system tables, back in 1999.

It turns out that DA had a "model of a model" for each database it supported, and it had this in a text file deep in the guts of DA. It wasn't hard to figure out how to read that text file. And Interbase sure reminded me of DSRI.

And how did I come to know DSRI? DEC Rdb/VMS was DSRI compliant. You knew I was going to come around to that, didn't you??? smiles. Received on Wed Aug 09 2006 - 13:03:42 CEST