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

"David Portas" <REMOVE_BEFORE_REPLYING_dportas_at_acm.org> wrote in message news:Q7adneDrYNW05PTanZ2dnUVZ8rGdnZ2d_at_giganews.com...
> "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.
>

The problem is that there are times when they can be answered and times when they can't. If that which identifies an individual can be different at different times, then simply comparing the relation value before the assingment with the one after will not work. For example, the number you pick at the pharmacy today may be different than the one you picked last week. It all boils down to key stability, and consequently whether or not the comparison is valid depends upon an arbitrary choice made by the database designer. In my opinion, that is unacceptable. Now if update is primitive, then key stability is no longer a factor because both the old values and the new values for each affected tuple are available, and therfore a tuple-by-tuple comparison can be carried out.

>> 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 don't see how it is attributing real world meaning to expect users to issue a DELETE to remove information about something that no longer exists, an UPDATE to adjust information about something that is different in appearance, or an INSERT to supply information about something that just came into existence. It is the user that can see what exists, what doesn't and what looks different; the system must be told. Is existence part of the external predicate? The domain closure assumption states that the only individuals that exist are those that are represented in the database.

Key values are supposed to map to individuals in the micro-world that the database represents. While it is true that a tuple can mean anything in successive states or even stand for multiple things, it is clear that since each tuple contains a key value, there is a mapping between that tuple and at least one individual in the micro-world. It is not the individual that is important here, but the fact that every tuple exhibits the same behavior, that is, under any interpretation, each key value exemplifies an individual. It is that behavior that supports the use of DELETE, UPDATE and INSERT in the manner described above.

>> 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).
>

The information is exposed in a FOR EACH ROW trigger. I think it could also be exposed in a manner that does not involve iteration.

> --
> David Portas
>
>
Received on Thu Dec 20 2007 - 16:03:41 CET