Re: A Normalization Question

neo55592_at_hotmail.com (Neo) wrote in message news:<4b45d3ad.0407261037.36bc4200_at_posting.google.com>...
> > > How to represent '(john take final) cause (john receive 95)' in RM?
> >
> > T_SVO
> > -----------------------------------
> > ID Subject Verb Object
> > thingA 'john' 'take' 'final
> > thingB 'john' 'receive' '95'
> > thingC ->thingA 'cause' ->thingB
>
> Is the above allowed by RM? Can an attribute (ie Subject) have both
> "scalar values" and references?

In the immortal words of Basil Fawlty, please try to understand before one of us dies.

(1) That *isn't* what I wrote. Why have you arbitrarily inserted quotes and little pointer arrows?

(2) Why are you determined to confuse representation with denotation? Just how many times do I have to say "I am *not* talking about representation"?

If you want to discuss representation, let us discuss possible representation schemes with respect to some semantic model. But there's really no point if you can't see the difference between model and implementation.

> Also, the above table indicates a person named 'john'. Name is an
> attribute of the person. How would one normalize that attribute so
> that changing it from 'john' to 'nhoj' would not result in an update
> anomaly?

I told you. If you wanted to do something like this, you would give John a unique identifier and use this to refer to John throughout the database. There would be a "Names" table mapping these individual identifiers to names. I can change the mapping for John's name by editing the John's row in the "Names" table. This is trivial.

> > and the table above is normalized in the sense that it contains no logical
> > redundancy (please note the careful use of the word "logical") there is
> > no row or column in the table that can be computed given the other rows
> > or columns.)
>
> While the above table may contain no redundancy within RM's limited
> scope/definitions, there are redundant things including the string
> 'john' which names a person and redundant symbols.

In the name of all that is holy...

> That string 'john'
> is redundant can be shown by the update anomaly that occurs by
> changing one of the string 'john' to 'nohj'.

Yes, yet again please refer to my point about the "Names" table.

> > So XDb2/TM cannot admit static type checking. Many of us in the
> > declarative programming community would see that as a serious problem,
> > both practically and logically.
>
> At the db engine level, there is no need for type checking because
> everything is a thing. The db engine is happy to relate 'john color
> blue', 'john color steel', john color book' etc. At the lowest level,
> it is not a db engine's business to decide which relationships are
> acceptable. XDb2/TM places the burden of type checking upon the
> application.

And this way lies madness and divorce.

I give up.

• Ralph