Re: What predicates the following relation represents

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Thu, 01 Apr 2004 00:38:27 +0200
Message-ID: <406b4865$0$559$e4fe514c_at_news.xs4all.nl>


Eric Kaun wrote:

>"Mikito Harakiri" wrote 

>>"Eric Kaun" wrote
>>>"Mikito Harakiri" wrote
>>>
>>>>SALES
>>>>=====
>>>>PART SOLD
>>>>---- ---
>>>>nuts 10
>>>>nuts 15
>>>>
>>>>Is SALES a legal relation? Is database really a repository of facts?
>>>
>>>Yes, a database is a repository of facts.
>>>
>>>It's a legal relation, though the external predicate to which it
>>>corresponds may be nonsense. You can always define a candidate key
>>>over all the attributes - that doesn't mean it makes sense to do so.

I have been reading this newsgroup for a few months now. One of the patterns I see is: Somebody writes an ambiguous example and starts asking questions which are unresolvable because of the ambiguity. A lot of speculation about requirements, some technical blabla, and sometimes a little object bashing follows.

One of the first things I learned about databases is *don't lie in your database* (maybe because I learned prolog first). In other words: make sure that all relation values in your database represent true propositions. A row conveys a fact.

The first step in achieving that is to provide a clear statement on the meaning of the rows: the predicate. Why do people keep forgetting that? In earlier posts I asked several times: 'what kind of facts are in your database' and 'what does is all mean'? I think this is an important step, to the point that is does not make sense to discuss a specific relation unless it's meaning is defined. Sure there is some exception when discussing the form only, that is, the syntax, (and even than there are some restrictions as to what a relation can mean) but anything beyond that requires a predicate, IMHO - or at least a serious effort to provide one.

If this looks like ranting I apologize. Both Eric and Mikito contribute interesting material.

>>Just a key. I never understood the difference between "primary" and
>>"unique", let alone "candidate". I guess they are mathematically
>>indistinguishable, that is why there is no decent definitions for those
>>adjectives.

> 
> 
> A primary key is an arbitrarily-chosen candidate key, and is downplayed by
> Date as being of little importance. UNIQUE is a SQL artifact, but could be
> interpreted as meaning candidate key. Candidate keys identify functional
> dependencies.
> 
> 

>>Key is fine, but what about the fact
>>
>><PART=Nuts, SOLD=0>
>>
>>Is it the same as the absence of the tuple?

[Quoted] In other words: what fact is conveyed? What does it *mean* ?

[Quoted] > Not necessarily - the above looks like a derived relation, rather than a
> base one. If it were a base one, given common-sense interpretations of the
[Quoted] > attribute names, I'd say the presence of the tuple was meaningless. If a
> derived one, then it has meaning - no nuts were sold. It's hard to say
> without understanding the requirements, but is certainly suspicious.

Requirements is much to broad. Meaning. Just meaning. Necessary and sufficient.

>>My humble interpretation is that the SALES table with attributes PART and
>>SOLD is still physical model. This relation on logical level is
>>
>>select PART, sum(SOLD) from SALES
>>group by PART

> 
[Quoted] > Agreed, that's probably the way it should be, but the SQL above isn't
> equivalent to the data you gave earlier, or nuts wouldn't appear twice.
> Perhaps there's some external predicate that might make the relation valid -
[Quoted] > but I doubt it. It's most likely simply poor design.

To achieve conceptual integrity one needs concepts. Received on Thu Apr 01 2004 - 00:38:27 CEST

Original text of this message