Re: relationship in the database

Paul Vernon <paul.vernon_at_ukk.ibmm.comm> wrote in message news:<am55eb$hac$1_at_sp15at20.hursley.ibm.com>...
> >Yes, but the question I tried to answer was what the equivalent
> >version of ON UPDATE CASCEDE would look like in the ER model.
>
> BTW I don't agree that ON UPDATE CASCADE have a place in the RM model.
If this is because you only want relational assignment through relational assignment, i strongly disagree. Do not wag the dog.
> Or at least the concept needs to be consistent with relational assignment. As > INSERT/UPDATE/DELETEs are only macros for relational assignment
> operations.

I have read about the concept of relational assignment, e.g. in "The Third Manifesto". While I like the concept very much, a (formal) definition about what it is would be an asset. This should include the effect with respect to triggers, referential integrity and primary (if such things exist) and candidate keys.

> Having both an ON UPDATE CASCADE and an ON DELETE CASCADE on
> one FK means that an UPDATE of a CK and an otherwise equivalent
> DELETE/INSERT statement pair can result in different database values. The
> question then is, what value would result if the operation was the
> equivalent relational assignment, rather than the UPDATE or DELETE/INSERT?
>
>
> Cascade actions that work differently depending on INSERT/UPDATE/DELETE
> can only properly be placed as part of the macro expansion of the I/U/Ds.

I can not follow you here.

> Amongst other things this implies that the users should be able to see
> (and review) the cascaded actions that are being suggested on their
> behalf.

Why? I agree that the programmer should be able to do so - at least to some extent - but that the end-user should care, I do not quite understand.

> It also implies that cascaded actions cannot be mandated, and so
> IMO they don't have a place in RM (or ER) model.

Why? If you could give me an example, i would be grateful.

>
> The only other option is to ban relational assignment. This was the SQL
> solution, and is one of its worst mistakes.

Why? If you can not agree on a formal model of assignment, the best solution surely is to ban it. If the choice is between relational assignment and tuple-wise (ie. you can't have both), and if the relational assignment can not provide you with the semantics needed, I favour the banning of relational assignment.

>
> Regards
> Paul Vernon
> Business Intelligence, IBM Global Services

Kind regards
Peter Koch Larsen Received on Tue Sep 17 2002 - 10:51:24 CDT