Re: Key attributes with list values was Re: What are the differences ...KEY

From: Brian Selzer <brian_at_selzer-software.com>
Date: Mon, 27 Feb 2006 05:01:29 GMT
Message-ID: <JIvMf.16831$2O6.2400_at_newssvr12.news.prodigy.com>


"Marshall Spight" <marshall.spight_at_gmail.com> wrote in message news:1140997530.409548.210860_at_t39g2000cwt.googlegroups.com...
> Brian Selzer wrote:
>> You asked for an example, so here goes.
>>
>> Consider the following set of propositions:
>>
>> Jane Harper is married.
>> Jane Smith is single.
>>
>> And a constraint that states that single people cannot become divorced.
>
> Your example is quite handwavey. You haven't specified what
> the attributes are. Is name a single attribute, or are first and
> last separate? What is the key? What is the constraint
> exactly?
>
>

I really didn't think I needed to state the obvious. The key is the name of a person. For the purpose of this discussion it doesn't matter whether it's modeled as a single attribute or two. Only the person's name and marital status belong to the universe of discourse. Here's an attempt at precision on the constraint: no update to the database shall be permitted that causes the marital status of a person to change from single to divorced.

>> It is impossible for you to know because that
>> information was not provided.
>
> This is a general limitation on all software, that it can
> only operate on information that it has been provided.
>

Nice dodge. Am I then to assume that you acknowledge the point?

>
> Brian Selzer wrote:
>> "Marshall Spight" <marshall.spight_at_gmail.com> wrote in message
>> >
>> > I'm not sure we're using the terms in the same way, though.
>> > Do you speak Java?
>> >
>> > Integer i = new Integer(1);
>> > Integer j = new Integer(1);
>> > System.out.println(i==j); // tests for identity
>> > System.out.println(i.equals(j)); // tests for equality
>> >
>> > Is that how you're using the terms?
>> >
>> > In Java, == on a reference type tests for reference equality,
>> > which is to say identity. If there were no reference types,
>> > as in Prolog or SQL or whatever, then there is no identity.
>>
>> That's the point: a non-1NF attribute is not scalar, hence the ambiguity.
>
> I observe you did not answer my question, but instead introduced
> new issues. I also observe that your post reversed the attributions
> between my comments and yours, which I have repaired.

My newsreader is Outlook Express. I wasn't attempting to reverse attributions. Is that how it's coming out on your reader? It isn't on mine.

>
> In any event, the above Java code illustrates equality and
> identity as I use the terms. Did you understand the example
> code?
>

Yes, I did. That's not how I'm using the term identity. I'm not referring to pointer arithmetic, but rather what makes something unique within a given context. In the context of a roll of quarters, each quarter has identity with respect to all other quarters in the same roll, perhaps determined by the distance from one end of the roll. In the context of a single database state, each proposition has identity with respect to all other propositions in that database state. For a relational database, the name of the containing relation combined with a value for one of its candidate keys is sufficient to represent that identity, but only for a single database state. If the database definition includes a temporal constraint, then it must be possible to correlate values from the current database state with values in the proposed database state. This means that the identity of a proposition must remain constant during an update, which is not possible if all candidate keys can change.

>
>> > Members of a set don't have identity.
>>
>> Yes they do. Is a roll of quarters worth 25 cents? No, and to elucidate
>> upon my previous point, the attributes that would uniquely identify each
>> individual quarter may not be relevant within the universe of discourse,
>> but
>> that doesn't change the fact that there are still 40 quarters.
>
> Again, it is a general limitation of software that it can only operate
> on the information it has.
>
>
>> > If you want a system that supports identity, you don't want to
>> > be using set theory. There are plenty to choose from, and
>> > they are well-supported and popular!
>>
>> Yes, I do want to be using set theory. The recognition of identity does
>> not
>> alter the sound theoretical foundation that the Relational Model
>> provides.
>> It strengthens it, or better yet, completes it.
>
> We still haven't really established what you mean by "identity",
> although you've said it's not the same thing as keys.
>
>
> Marshall
>
Received on Mon Feb 27 2006 - 06:01:29 CET

Original text of this message