Re: Database design, Keys and some other things

From: JOG <jog_at_cs.nott.ac.uk>
Date: 27 Sep 2005 10:21:53 -0700
Message-ID: <1127841713.066020.184620_at_z14g2000cwz.googlegroups.com>


I think it comes down to the fact, it is easy to confuse a predicate with the situation it describes, but there is a real difference. Consider the predicate:

"The sky is blue in the daytime"

This has may be represented a a set of three items {sky, blue, daytime}. But we can say some extra things about this set. First who stated it - me. Second when it was stated. Third that it is the first thing I have said on the matter. Fourth, we can comment on the truth of the statement - that it, in england, is only true.. say 25% of the time. tops.

Now these are all pieces of information about the PREDICATE itself, not the situation it describes. They are metadata, and encoding them with the information about the situation is entirely incorrect - they are attributes of the container, not of the content.

Mathematically we might write:

P = {"sky", "blue", "daytime"}
Author = {(P, "James")}
Created = {(P, "27th Sept 2005")}
etc...

Saying { sky, blue, daytime, James, "27th Sept 2005", 25% } is wholly wrong. It is a confusion of data and meta data.

A surrogate key, created specifically to represent a statement, is no different. It is an artificial way of referencing the predicate. This is meta_data about the predicate and has no place existing in the same area as the elements of the predicate - the real information, that exists in the real world. Received on Tue Sep 27 2005 - 19:21:53 CEST

Original text of this message