Re: Enforcing functional dependecy constraints

From: David Cressey <dcressey_at_verizon.net>
Date: Thu, 15 Dec 2005 15:58:20 GMT
Message-ID: <wogof.2238$1b.883_at_trndny03>


"x" <x_at_not-exists.org> wrote in message news:dnmkef$ge7$1_at_domitilla.aioe.org...

> > > This is the standard theoretical decomposition.
> > > How the AB->C is enforced ?

> > > a)R(A,B,C) with (A,B) primary key, (B,C) foreign key into T and
T(B,C)
> > with
> > > C primary key.

OK, I've been thinking this over, and I've got a solution that works with just one table, but I'm not willing to publish it.

In the first place, it probably has bugs in it, and I'm not prepared to debug it. In the second place, even if it turns out that it's bug free, I still don't want to put it in a public place, with my name tacked to it. Here's a synopsis (with single letter names instead of the names that would be used in a "real" example".)

CREATE TABLE R (

    A INTEGER,
    B INTEGER,
    C INTEGER,

    PRIMARY KEY (A,B),
    CHECK NOT EXISTS (SELECT horrible code goes here));

I think DEC Rdb (Oracle Rdb) allows this construct.

The horrible code is designed to enforce the rule that C determines B. I'm omitting this part.
The primary key enforces A,B determines C. Note that the table is not in BCNF, so update anomalies still have to be dealt with in programs.

If I ever did this in the real world, it would be as a sort of prank, and not as an exercise in professional, disciplined data base design.

The net effect is very much like using a trigger, but it's at least declarative. Received on Thu Dec 15 2005 - 16:58:20 CET

Original text of this message