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

"Bob Badour" <bbadour_at_golden.net> wrote in message news:TtkKa.509$LI6.68898946_at_mantis.golden.net... [snip]
> > >What do you propose for logical independence if not views?
> >
> > Alternate, information equivalent, database schemas.
>
> And how does this differ from views?

Because to the user of a particular database schema sees as a table, what a user of an alternate schema would see as a view. Giving a user a view and telling him it's a table is not good enougth unless the catalog reflects that fact (including showing that any tables that the view is based on are actually views, and acuratly reporting the constaints on the table that used to be a view).

In otherwords, the concept of views does not properly capture the 'schema switching' process that should (logically) occur when you want to treat a set of views as tables

[snip]
> 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.

Agreed.

(I think) my point was meant to be more about the contradictions of multiple assignment. In particular I'm no fan of this sentence from the manifesto (page169 2nd Ed):

    "Note that the overall result [of a multiple assignment] might be unpredictable if the target variables T1, T2, ..., Tn are not all distinct"

I don't want any possibility of "unpredictable results" in my DBMS (short of explicitly calling non-deterministic functions such as RAND())

What does it mean to assign two values to a single variable "in parallel" as the TTM allows with multiple assignment?

To me, the thing that is broken is not (particularly) multiple assignment, but view updating. If we did not have view updating, then we could just limit multiple assignment to assigning values to relvars just once, but with view updating we have to allow one relvar to be updated twice.

The alternative of banning views as targets in multiple assignment smacks of a hack, so I just go for banning views as targets of assignments at all :-)

[snip]
> > Then what about these macros?
> >
> > INSERT INTO A VALUES (1,'A'), (2,'B'),
> > DELETE FROM B WHERE j = 'B';
>
> Macros?
> Do macros have preconditions?

D&D's do. Well, post-conditions anyway. However they don't define them as part of some macro expansion expression. That would involve a model of exceptions other than plain constraint breakages for one. No, they just give us the semantics of say INSERT (page 166), where the cardinality after the insert should be that of the before insert plus the number of inserted rows.

Personally I one reason why I would like INSERT to not fail on duplicates is precisely because one could then define such a macro expansion expression without worrying about 'duplicate insert exceptions '

[snip]
> We have no way to force every user to read and to fully comprehend the
> catalog prior to presenting data.

Of course, but if they do fully check their incoming data and update statement against the catalog constraints, then they should be guaranteed that the update will work. I.e. none of this view updating stuff where all the constraints on the view are not in the catalog. For Chris, all views are updatable, but you have to try an update and see if it actually works to know if a view is updatable in practice!

> Thus, we have no way to prevent users from
> presenting contradictory data. The integrity function automates the task of
> checking the data for users.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Wed Jun 25 2003 - 19:28:21 CEST