Re: A real world example

paul c wrote:
> erk wrote:
> > Probably true - on its own, the word "attribute" implies a thing (noun)
> > its value is attributed to.
>
> I'd agree that for many people there is such an implication (but I'd
> rather use the word 'suggests' rather than 'implies').

I agree, that was sloppy on my part.

> 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.

Yes, that association depends on the meaning of the predicate. The various definitions of the verb "attribute" imply a source, person, or thing that the value is inherent in. There's definitely a "conceptual containership," while attributes of relations are placeholders for specific values about which statements are being made.

>> 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.

By consistency, I meant the more general case of consistency between N different predicates - being able to limit statements by reference to other statements. All that can be derived only from what we know about the real-world domain that we're modeling, and the invariants we need to enforce.

In most cases, those constraints involve only a small subset of the database's relvars, but it needn't be so.

> [...] 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.

I agree with the spirit - relations are the first principle of relational (note to self: duh).

> 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.

What do you mean by "implications using join"? A domain mustn't be defined by reference to relvars.

• erk