Re: more closed-world chatter

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:SGn%h.162518$DE1.14036_at_pd7urf2no...
> Jon Heggland wrote:
>> Marshall wrote:
>>
>>>On May 5, 8:50 am, Jon Heggland <jon.heggl..._at_idi.ntnu.no> wrote:
>>>
>>>>>when it comes to the advantage of sub-typing in dealing with
>>>>>my question.
>>>>
>>>>I don't know about "advantage"; I just don't see how you can avoid it.
>>>
>>>It's easy to avoid: just don't put subtying in the language design.
>>
>>
>> I didn't mean how to avoid subtyping per se; I meant how to avoid it if
>> you want to be able to join on attributes with different types.
>
> 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.
>
> Also, I believe Codd originally envisioned no attribute names, just domain
> names, ie., types and added attribute names later, in part at least, to
> allow for bills of materials/parts explosions.
>

I don't think that's entirely correct. He specified that attribute names distinguish the roles a particular domain plays within a relation. The reason being that the same domain could appear multiple times in the same relation schema, and he felt that order should be dispensed with.

I really don't understand what all the confusion is: perhaps it is caused by conflating domains with types. A domain is simply a named set of values that is specified or enumerated as part of the schema. A type, on the other hand, describes a class of values, focusing not on set membership, but rather on similarities among the values--common properties, if you will. Absent further statements about domains, the only comparison possible between members from a domain is equality, and comparison of values from separate domains is not possible. The statements that describe the properties of values within a domain and statements about how elements from one domain can interact with those from another provide the means whereby comparisons beyond equality for values from a single domain and comparisons of values belonging to separate domains can be accomplished. For example, if there is a domain named HOURS and a domain named SECONDS, how can their elements be compared, unless the relationship between the elements in HOURS and the elements in SECONDS has been stated as part of the schema. So from the standpoint of RT, a type is more a set of constraints than a set of values. By limiting the elements of a domain to a particular type, those elements can be compared to elements of a different domain, provided it is also so limited. A type subsystem provides a framework for describing domains and the possible interactions between values from them.

> If it is understood that all the relations in a given db obey the D&D
> stipulation, then I think what Marshall is musing about is a valid choice,
> it could be thought of as an implementation preference that doesn't deny
> the rest of the D&D premises. But if a dbms is aware only of attributes
> and not their domains/types it would still be necessary for every
> attribute in the db to have its operators, beyond an equality operator, if
> any, to be defined. Since domain or type names are likely fewer than
> attribute names, this would be less economical than requiring one
> domain/type name for each attribute.
>
> With this view of things, maybe I didn't need to ask the question in the
> first place!
>
> p
>
>
Received on Mon May 07 2007 - 15:36:23 CEST