Re: A simple notation, again

From: paul c <toledobythesea_at_oohay.ac>
Date: Tue, 17 Jul 2007 03:03:28 GMT
Message-ID: <4kWmi.125098$1i1.56624_at_pd7urf3no>


Bob Badour wrote:

> David Cressey wrote:
> 

>> "Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message
>> news:469bac76$0$8868$9a566e8b_at_news.aliant.net...
>>
>>> David Cressey wrote:
>>>
>>>
>>>> Using the notation [A B C] for <NOT> (A <AND> B <AND> C), etc.
>>>>
>>>> The following [ A [B]] means "A implies B" for Boolean algebra.
>>
>>
>> What is
>>
>>>> the corresponding thing for Relational Algebra?
>>>>
>>>> Also, I'm trying to come up with a bracket notation for a "literal
>>>> relation", like literals for simple datatypes like numbers and
>>
>>
>> character
>>
>>>> strings.
>>>>
>>>> I'm toying with this:
>>>>
>>>> [["David" "Cressey" 1]
>>>> ["Marshall" "Spight" 2]
>>>> ["Bob" "Badour" 3]
>>>> ["Jan" Hidders" 4]]
>>>>
>>>>
>>>>
>>>> This would represent a relation of order 3 and cardinality 4.
>>>>
>>>>
>>>> What I don't like about this is that the binding between attribute
>>
>>
>> values
>>
>>>> and attribute names is
>>>> by position rather than by name, and in fact the attribute names don't
>>
>>
>> even
>>
>>>> appear here. That's unacceptably bad. The symmetry is appealing, but
>>
>>
>> it
>>
>>>> clearly needs improvement.
>>>
>>>
>>> You omitted names entirely. You would have to extend the syntax to
>>> something like:
>>> [[name="David" surname="Cressey" n=1]
>>> [n=2 name="Marshall" surname="Spight"]
>>> [surname="Badour" name="Bob" n=3]
>>> [name="Jan" surname="Hidders" n=4]]
>>
>>
>>
>> Yeah, that'll do it, all right. To be consistent with the former
>> notation,
>> each attribute=value pair needs to be construed as a relation of order
>> 1 and
>> cardinality 1.
>>
>> The extended <AND> of a single name, a single surname, and a single
>> n, will
>> be the cartesian extended product, which will be a relation of order 3
>> and
>> cardinality 1.
>> Outside the inner bracket, what we have is the <NOT> of this, which
>> I'll
>> call the <NOT> of a <TUPLE>. Where <TUPLE> means a relation of
>> cardinality
>> one.
>>
>> We have four of these <NOT> of a <TUPLE>, connected by an extended
>> <AND> .
>> This time the extended <AND> resolves to the intersection of the
>> operands,
>> bercause all the operands have the same attributes.
>>
>> So inside the outer brackets we have the intersection of a collection of
>> <NOT>s of <TUPLE>s.
>> This is equivalent to the <NOT> of the union of the <TUPLE>s. Outside of
>> the outer brackets, we have the <NOT> of the <NOT> of the union of the
>> <TUPLE>s, This is the union of the <TUPLE>s, which is the desired
>> relation.
>>
>> Does this make any sense at all, from a mathematical perspective? I am
>> definitely in over my head, here.
> 
> 
> Yeah, I followed it when you posted it. I will leave it for Jan or Vadim 
> to answer whether A UNION B = NOT( (NOT A) JOIN (NOT B))
> ...

I think I follow it too, at least as far as the D&D TTM-A algebra is concerned and it gibes with any example I've ever tried to work through as long as I followed the closed-world-assumption that D&D follow.

ie. de Morgan's law applied with TTM-A means A <OR> B being true implies <NOT> ((<NOT> A) <AND> (<NOT> B)) being true and vice versa. But why ask the question using "UNION", "NOT" and "JOIN" unless they are defined differently than D&D define them?

Also, this gives me an excuse to mention one of my pet penchants again.   <NOT> (A <OR> B) is the complement of a union in D&D terms and when A <OR> B is true, it implies that (<NOT> A) <AND> (<NOT> B) is false. I find it interesting to think about a relation's complement when thinking about insert to "union". When A and B have the same heading and we insert a single tuple to a view that is A <OR> B, some people say inserting to one or the other of A or B is just as logical as inserting to both A and B, so we can't really decide what to do. But it seems reasonable to me that the complement of the view must also respect the complements of A and B, so neither of those complements should contain the inserted tuple, which means that both A and B would contain it after the insert.

p Received on Tue Jul 17 2007 - 05:03:28 CEST

Original text of this message