Re: delete cascade

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:y9PWh.115941$DE1.92555_at_pd7urf2no...
> Brian Selzer wrote:
>> "paul c" <toledobythesea_at_oohay.ac> wrote in message
>>> Eg., the rva has an attribute that references the invoice# in the same
>>> relation that has the rva as an attribute.
>>>
>>
>>
>> Including invoice# in the header of the rva would be redundant because
>> for each element of the relation, every tuple in the value for the rva
>> would have the same invoice# as the element containing the value. ...
>
> Well, if the view had been formed by a join of invoices and items and the
> only common attribute was invoice# and then some of the other attributes
> were grouped, invoice# would appear in only one of the headers.
>
> That is different from saying invoice# in the rva is always redundant
> which would preclude a relation with invoice# as an attribute of both
> headers, for example, the tuple {invoice# x, rv {item#, invoice#}} where
> rv is empty. I'm not quite sure what use such a relation would have, but
> I don't see why one should take steps to prevent it if we can express it.
>

Actually, the tuple {invoice# x, rv {item#}} would work just as well, unless the invoice# in the rv could possibly refer to some other invoice???

> (By my definition, regardless of whether rv were empty, rv.invoice# could
> reference the "first" invoice# attribute.)
>
>
>> ... Since a tuple is a value, not a variable, the rva containing the
>> items would be assigned at the same instant as the containing tuple.
>> This eliminates the need for a referential action. The thing I don't
>> understand is why Bob suggested using a view. If composition rather than
>> aggregation applies, then make the rva part of a base relation. A view
>> would add unnecessary complication to the schema, leaving room for human
>> error. I also am mystified that he mentioned cascading updates: from
>> what he has said in earlier posts, keys can't be updated, and if keys
>> can't be updated, there's no need for cascading updates.
>
> On a logical level, I don't know what a "referential action" is. I am
> supposing it means the same as "reference". (I'm not sure I've ever
> understood why the foreign key kind of reference is not called implication
> as its definition seems to take the same form as logical implication.)
>

I know it sounds backwards, but a foreign key constraint describes a whole-part relationship, with the referencing, or "child," relation taking the role of the whole and the referenced, or "parent," relation taking the role of the part. All of the attributes values from a referenced tuple can be thought of as being an integral part of the referencing tuple. Therefore, any update to an attribute of a part should automatically be reflected in the whole, regardless of whether the attribute is prime. By its participation in a foreign key constraint, a key takes on its own identity within the database, meaning that whenever that key is updated, that update must also be reflected in every referencing tuple. A cascading update relies on the concept of logical identity in that there is theoretically only one value for a key, regardless of the fact that that key value may appear not only in the referenced tuple, but in numerous other referencing tuples throughout the database. For cascading deletes, on the other hand, the roles are reversed. The only time that a cascading delete should be allowed is when the entities represented by each referencing tuple are not only a part of the entitiy represented by the referenced tuple, but also are controlled with respect to lifetime by the entity represented by the referenced tuple. The line items of an invoice fall into this category. That's why you can use a relation valued attribute for line items in the schema for an invoice.

> It is more Bob B's introduction of an rva that I am struggling with, so
> far I am guessing that it has to do with the ability to delete all items
> by deleting a single tuple.
>
> p
Received on Mon Apr 23 2007 - 04:38:18 CEST