Re: relationship in the database

>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. Or at least the concept needs to be consistent with relational assignment. As INSERT/UPDATE/DELETEs are only macros for relational assignment operations. 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. 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. It also implies that cascaded actions cannot be mandated, and so IMO they don't have a place in RM (or ER) model.

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

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Mon Sep 16 2002 - 19:43:43 CEST