Re: more closed-world chatter

From: paul c <toledobythesea_at_oohay.ac>
Date: Sun, 06 May 2007 17:21:11 GMT
Message-ID: <b8o%h.162591$DE1.122575@pd7urf2no>

Marshall wrote:
> On May 6, 9:49 am, paul c <toledobythe..._at_oohay.ac> wrote:
>

>>Not to distract my betters on this topic, but I guess I should have
>>originally mentioned that I think the D&D stipulation "It is required
>>that if <A,T1> is in Hr1 and <A,T2> is in Hr2, then T1 = T2" could be
>>gotten around simply by ensuring that no two relvars have such an
>>attribute.  This would be easy for a "catalog" to enforce.

>
>
> Sure, that works. But it doesn't thrill me; it means that now you
> might be trying to create a relvar and fail because of some
> other relvar that you're barely aware of.
>
> My latest thinking is just to take T1 and T2 out of the header
> and put them on the constraints. That means you don't need
> any second-order constraints like the one you propose, and
> it furthermore means you can join any two relations and be
> sure of getting a relation. (I.e. closure.)

(I didn't think I was proposing second-order.)

I was imagining a catalog table/relation such as TYPES{attributename,type} where attributename is key, which I think is what you mean too.

It doesn't bother me (yet) that I might fail to create a relvar because an attribute was already defined with a different type because, once all relvars were defined, I would rather have an engine that would operate with as few exceptions as possible.

Also, earlier, I think Jon H said something like "constraints are associated with relvars". I would rather say constraints mention relvars. Because they may mention more than one, I would rather think of them as being associated with a db.

p Received on Sun May 06 2007 - 12:21:11 CDT