Re: A real world example

erk wrote:
> JOG wrote:

>> Originally Codd used the terms "roles and values" in the
>> 1970 paper. Perhaps the commonm use of 'attributes and values' to
>> describe a relation encourages the "thing-oriented" approach.

I'd agree that for many people there is such an implication (but I'd rather use the word 'suggests' rather than 'implies'). Personally, at the level of a dbms, I like 'attribute' but I'd rather think of 'attributing' in a very narrow way that doesn't invite comparisons with some external reality, eg., when I fasten an attribute to a relation, all I'm doing is associating some domain's values with values of other domains. It is up to users to agree on some interpretation, not for the system to try to do.

> I try to remember Date's loose analogy of predicates as sentences, and
> attributes as nouns in the sentence. A predicate is a type of
> statement; each tuple is a specific statement about specific values, a
> statement we assert is true (and Closed World means those not in the
> database are assumed false). Constraints, then, are our means of
> keeping statements consistent in meaning, since the DBMS can't know the
> real-world meaning of any of them.
>
> I'm not sure "roles and values" is any better; "predicates and free
> variables," or "predicates and terms," while less intuitive, are as
> close as I can get.
>
> - erk
>

More good stuff. Even though many here have read Date, I think it's not   repeated enough (even though I'm a bit ignorant about the/any formal connection between set logic and predicate logic). I'd quibble a bit about "constraints ... keeping statements consistent" - I tend to think that in the first instance it is relations that do that whereas constraints are a convenient way of making sure all apps don't exceed the range of values intended nor the intended range of mappings among values. Put another way, I think the act of defining a relation is defining the 'first constraint', so to speak.

Also (and I know I'm going a bit off-track here), saying a salary can't be more than say, $10,000, might be thought of as a domain constraint, not a relation constraint, but I think that would mean some sophisticated type support in a dbms, eg. to come up with implications using join. Whereas saying the salary must be less than such-and-such if the job is clerk is more of a relation constraint.

p Received on Thu Aug 17 2006 - 19:10:01 CEST