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

"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.

> > > 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)

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.

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';

> > > 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. If not, then of course the constraints stop the database value being altered to one that breaks the constraints.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Wed Jun 25 2003 - 12:27:24 CEST