Re: more closed-world chatter




"paul c" <toledobythesea@xxxxxxxx> wrote in message
news:SGn%h.162518$DE1.14036@xxxxxxxxxxxx
Jon Heggland wrote:
Marshall wrote:

On May 5, 8:50 am, Jon Heggland <jon.heggl...@xxxxxxxxxxx> 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




.



Relevant Pages

  • Re: Nexus Programming Language
    ... just to avoid the whole confusion. ...
    (comp.lang.ruby)
  • Re: Announcing New Blog
    ... > flawed because they do not take some important things, such as schema ... Database systems is an evolving environment. ... > practical to eliminate nulls. ... > avoid the introduction of nulls seems silly at best and could be both ...
    (comp.databases.theory)
  • Re: OOP Terminology - another word for "user"
    ... interact with instances of this class, ... Use "client code", frequently enough to remind people of what you are ... avoid that except in the cases you mention. ... Note that, by default, the logger will not ...
    (comp.programming)
  • Re: Enable a service for interaction with the desktop
    ... not going to support his option in Vista. ... that you avoid using Interact with Desktop as it is NOT reliable if your ... Good luck, but if you can avoid any interface interaction via your service, ...
    (microsoft.public.dotnet.general)
  • Re: Goshuushou-sama Ninomiya-kun - My take
    ... interact - IE might be shutting down in order to avoid what it thinks is ... a virus. ...
    (rec.arts.anime.misc)