Re: Database design, Keys and some other things

JOG wrote:
> David Cressey wrote:
> > I've seen an interesting way of presenting this idea, or a similar one.
> > The authors call what the database serves up 'opinions' rather than
> > 'facts'. That is, 'in the opinion of the database, the employee with
> > employee id 12345 has first name "Marshall" and last name "Spight"'.
> > Or, 'in the opinion of the database, there is no employee with id 567890'.
> > Or 'the database has no opinion as what Donald Trump's e-mail address might
> > be, if he has one'.
> > I find this enormously refreshing, especially when it comes to missing data.
>
> I like that a lot. 'Facts' about the world are pretty subjective even
> within scientific fields. Opinion is a lot more apt (Way back in the
> thread, when I attempted to offer an example of the distinction that
> can be made between a tuple's properties and the attributes that make
> up the 'fact', one was confidence a measure - there is a lot of
> research currently being done in the area). Imo ;)
>
> Marshall Spight wrote:
> > I guess you're saying it's profound that there's
> > nothing profound to be said about the relationship between
> > internal and externa predicate. I guess I could buy that
>
> The Hofstadter view has a lot in common with this interpretation - that
> information arises from data + intelligent processing (he highlights

I am trying something slightly different: 1) To make data + knowledge about mentioned data 2) To store data + knowledge about the data into the database.

But there are the problems. We can have more "records" in the database then in the Real World and some of them are not covered by theory's definitions.
Some "records" are wrong, some keys can be wrong or a data can be wrong. Facts about data can be wrong. Sometimes there are different knowledge related to one data.
I know for the case when the company sued a person who had died. (just a small joke about knowledge for Sunday's afternoon) In all these cases I prefer solution which can effectively say what is wrong,
what causes that ... Like in the Real Life, where we have the effective procedures (usually effective) by which we can see what is false.
In my example 2.5 the first row (with key 116) can be repeated many times during one day. Paul Jones can open and close this row for example 10 times, so that we have same rows (except the key's values, which can be hidden). Should we forbid this? I prefer not. I believe that rows with same values can have some sense. This key now has not sense regarding the Real World. But it has sense regarding Paul Jones. We can see that he created these keys; maybe he tried crime with saving accounts?
So we will say these keys are wrong but also we will use them as the specific information.
Now let us consider that I am selling my application or the application is working in my company. In both cases I don't want to argue with the end users and with the managers about wrong date. I can build one screen for an authorized person so that he/she can effectively find what's happening. And this screen is possible because I have effective solution which exactly says what happened, even if somebody enters the same rows. All this has relationship with knowledge and meaning in wider sense. Meaning is not related to just one number. I will quote Date regarding surrogates once again from Anith Sen message:
"Their values serve solely as surrogates (hence the name) for the entities they stand for.
In other words, such values serve merely to represent the fact that the corresponding entities exists - they carry no additional information or meaning whatsoever."
So we can have a database for example for some meeting and assign numbers to the members of the meeting in the database. As Joe write it is important to have external verification. So we will distribute the badges with corresponding numbers and they are only for the identification of the existence. The badge's number doesn't have meaning for you, like meaning of a person's name who you know very well. It depends on many sources of knowledge.

> grooves on a record as an example of data, intricately patterned and
> organised, yet completely meaningless without that external
> translation). A db should facilitate making that translation as simple,
> and as accurate to the creator's orginal opinion, as possible.
>
> > We were discussing whether there was a difference between
> > the natures of external ids vs. surrogate keys. What is
> > essential to this question is what their nature is. Generally
> > we do not regard context-specific considerations as essential.
>
> I'm not sure context is the right line. As far as a specific database
> is concerned a VIN is not a surrogate key, its a natural. And to me,
> well, that's the key distinction (no pun intended). A surrogate exists
> solely to help facilitate the internal predicate that you
> distinguished, and has nothing to do with the external predicate.
>
> all best, J.
Received on Sun Oct 02 2005 - 21:33:01 CEST