Re: Distributed foreign keys (was Re: Category Types)

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:bdbtj8$1l0u$1_at_gazette.almaden.ibm.com...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> news:bp3Ka.439$8s4.63102067_at_mantis.golden.net...
> [snip]
> > I assumed your objection to view updates was an objection to the update
part
> > and not to views themselves.
> > Was I wrong?
>
> Prety much. I do object to how views are currently defined and used in the
> relational model!
>
> >What do you propose for logical independence if not views?
>
> Alternate, information equivalent, database schemas.

And how does this differ from views?

> > > > One can
> > > > always safely attempt to insert contradictory data,
> > >
> > > Assuming one can present such contradictory data to the DBMS in the
first
> > > place.
> >
> > What would prevent one from presenting contradictory data?
> >
> >
> > > In the case of 'duplicate data', I suggest it is simply not possible
to
> > > try to insert 'duplicate data' into a database.
> >
> > Are you suggesting that "insert" should be equivalent to a union
assignment
> > without any preconditions?
>
> Not here, altough on the point, INSERT is just a shorthand, so if I could
> define my own shorthands, I could have INSERTs that either do, or do not
have
> pre-conditions.
>
> Here I am saying that it is not (or at least should not) be possible to
> 'present' data to the database that is either contradictory or has
duplicates
> to the database for insert. I.e. the only thing you can present to a
database
> are relations, and relations cannot contain duplicate or contradictory
data
> (ignoring the issue of whether such presented data is a duplicate or
> contradictory with data in the database)

One can present a relation to the dbms that contradicts the predicate for the database. Nothing prevents one from presenting the contradiction; the integrity function prevents the contradictory data from corrupting the database.

> With views and multiple assignement, you can insert both contradictory or
> duplicate data to the database.
> E.g.
> with
> TABLE A (i INT PRIMARY KEY, j CHAR(1) NOT NULL
> and
> VIEW B AS SELECT * FROM A
>
> the mulpile assignment
>
> INSERT INTO A VALUES (1,'A'), (2,'B'),
> INSERT INTO B VALUES (1,'A'), (2,'C');
>
> Is presenting the database with both contradictory and duplicate data.

One does not need B to present the contradictory information nor does one need a multiple assignment, so the example is just a straw man.

If we have:

VAR A RELATION { i INT, j CHAR } KEY { i } ;

A := RELATION{ TUPLE{ i INT(1), j CHAR('A') }, TUPLE{ i INT(2), j CHAR('B') }}; and we present the following assignment, we present a contradiction.

A := A UNION RELATION{ TUPLE{ i INT(2), j CHAR('C') } };

In the above, we present only relations in a single assignment and yet we present a contradiction. Both operands of the UNION are relations as is the result. However, the key for the result of the UNION is { i, j } and the values in the result are incompatible with the key of A.

If, instead, we present the following assignment, we do not present a contradiction:

A := A UNION RELATION{ TUPLE{ i INT(3), j CHAR('C') } };

In this case, the key of the result of the UNION is still { i, j }, but the incidental values are compatible with the key of A.

> My questions is, what does the expansion of the above INSERT macros look
like
> in terms of an attempted database assignment?
>
> Then what about these macros?
>
> INSERT INTO A VALUES (1,'A'), (2,'B'),
> DELETE FROM B WHERE j = 'B';

Macros? Do macros have preconditions?

> > > > and to ensure safety,
> > > > the integrity function should always make such attempts fail.
> > >
> > > I prefer to know before hand (i.e. statically) if my updates attempts
will
> > > fail. Thowing a plausable update at the database and hoping it will
stick
> > is
> > > not a great approach.
> >
> > That's fine for you. However, I do not think it is a good idea to assume
> > every user will have perfect knowledge of all constraints. It should be
safe
> > for a user to present contradictory data, which then becomes an
educational
> > opportunity. What does the integrity function provide if not such
safety?
>
> That 'perfect knowledge is, has to be, available in the catalog, so they
can
> look there if they wish to statically check their statements.

We have no way to force every user to read and to fully comprehend the catalog prior to presenting data. Thus, we have no way to prevent users from presenting contradictory data. The integrity function automates the task of checking the data for users.

> If not, then of
> course the constraints stop the database value being altered to one that
> breaks the constraints.

Of course. Received on Wed Jun 25 2003 - 17:56:30 CEST