Re: Newbie question about db normalization theory: redundant keys OK?

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:4leaj.56191$eY.1078_at_newssvr13.news.prodigy.net...
>>
>
> If assignment is primitive, then it cannot necessarily be determined
> whether the properties of an individual that existed before an assignment
> are now different or that an individual that did not exist before the
> assignment now does.

Both those questions could be answered by comparing the relation value before the assignment to the one after it. For reasons that aren't clear to me you think that is not allowed or invalid in some way. I think I'm not the only one who will take some convincing.

> If, on the other hand, update is primitive, then there is no doubt. Since
> an update specifically targets information about what already exists, and
> since the update includes information about those individuals both before
> and after, there is no doubt as to whether the individuals in question
> existed. This is what I mean by "cannot be verified."
>

To attribute any real world meaning to a humble operator is a bizarre leap beyond RM. RM says absolutely nothing about semantics. One tuple could mean anything in successive states of the database or even stand for multiple things in the same state. I can't imagine saying to database users "Use updates if you mean that this particular individual already existed. Use other operators if you mean something else." I for one wouldn't want to have anything to do with such a DBMS!

> I think I indicated that the result may be the same. If I want a new
> Ferrari, I can buy one or I can steal one. In both cases the result is
> the same--I would possess a new Ferrari--but how I ultimately arrived at
> that result is significant, because in the one case I would be in debt up
> to my eyeballs, but in the other case I would be on the run from the law.
>

Yes but you are totally failing to explain HOW or WHERE that information could be exposed. If it does not exist as values within relations then it does not exist in an RDBMS. If it does exist as values within relations then it can be supported equivalently using an assignment (or at least using multiple assignment).

-- 
David Portas