Date: Tue, 8 Jul 2008 01:02:41 -0400
"paul c" <toledobysea_at_ac.ooyah> wrote in message
> Brian Selzer wrote:
>> Consider the following statements:
>> 1. Susan is an electrical engineer.
>> 2. Susan is a mechanical engineer.
>> 3. Susan is an electrical engineer or Susan is a mechanical engineer.
>> Now, suppose you have a base relation P whose members map to individuals
>> that exemplify the property of being an electrical engineer, a base
>> relation Q whose members map to individuals that exemplify the property
>> of being a mechanical engineer, and a virtual relation (a view) R (P
>> UNION Q) whose members map to individuals that exemplify either the
>> property of being an electrical engineer or the property of being a
>> mechanical engineer or both. The presence of a tuple in the virtual
>> relation with a value that maps to Susan tells us only that Susan exists
>> and that she is either an electrical engineer or a mechanical engineer or
>> both. It does not tell us which.
> That is your interpretation. (I don't like words like 'members' and 'map'
> in this kind of example so I'll assume you don't mind me thinking of
> 'members map' as 'tuples stand for'.)
> However, I'm content to say that all three relations have the same
> predicate, assuming no attribute renaming is involved in your
> interpretation. I know many people say that the 'or' is introduced to the
> predicate of R. I don't believe there is any law or principle, including
> relational closure, that requires anybody to think this way.
How can they have the same predicate if they can have different extensions? That doesn't make any sense.
> Also, assuming your example involves single-attribute relations, I'd say
> it is basically the same as Codd gave in his 1990 book, which I think is a
> straw man.
> If the above relations have only one attribute, such as 'person_name',
> then I think you are imputing meaning to the relation names (R, P and Q)
> and expecting a dbms to somehow do the same. If they had a second
> attribute, such as 'qualification', then I would say all three relations
> have the predicate "person has name 'person-name' and qualification
I don't expect a dbms to impute meaning, since that is not its function nor within its capability. Meaning is assigned under an interpretation, which only a person can do. However, interpretation of first order sentences involves the assignment of meaning not only to individual symbols but also to predicate symbols. Constant symbols from the various domains defined on the database are individual symbols; relation names are predicate symbols.
> I'm quite happy to distribute union or D&D's '<OR>' over the view
> expression, eg. R =: (P <OR> <inserted relation>) <OR> (Q <OR> <inserted
> relation>) and not bothered if millions upon millions of people think that
> such a dbms is not useful.
> I think that what R = P <OR> Q "means" is that at any time, R always
> reflects what facts have been inserted to P and Q and says nothing about
> what has been inserted to R. If this is what David McGoveran means by
> POOD, I agree with him. People who know much more about computer
> languages than I have said this is non-deterministic behaviour, which is a
> nuance that has always escaped me. If they are right in the narrow scope
> of automation languages, I'm still not bothered.
> Also, I'm happy to distribute over any view expression, difference,
> conjunction, etc., in any way that boolean logic allows. When it
> comes to projections, we get to the perhaps obscure area that I'm most
> interest in because I imagine something very fundamental must change, not
> just the notion of 'insert', but Codd's 1NF as well as the projection
> operator / aka existential quantification, itself.
Received on Tue Jul 08 2008 - 07:02:41 CEST