Re: No exceptions?

Bob Badour wrote:
paul c wrote:

Bob Badour wrote:

paul c wrote:

J M Davitt wrote:
...

It almost seems as though you want to declare an analogue for DUM,
syntax-check some expressions, and add attributes to your relation
with the confidence that your expressions are still correct.

Not exactly how I thought of it, but I think that's fair, after all, one can add attributes, subject to one's external conception, to relation definitions that don't have empty headings, in fact not that the observation is of any use, that seems to be what happens when one defines a relation with one attribute.

I suggest an empty candidate key in a relation with any number of attributes is closer.

I don't catch your drift. If we are on the same page, then trying to equate a relation that has either no rows or one row with a relation whose name is mis-spelled is indeterminate. If doing that is the same then I would have to give up on my original question.

You suggested that adding an attribute to a degree zero relation is a degree one relation. However, whether one adds one attribute or an arbitrary number of attributes is less important than the fact that the candidate key will have an empty set of attributes.

Maybe a fine point, but...

All the attributes in a relation comprise, at least, a superkey. The
set of attributes that qualify as a candidate key must hold unique values and no subset of those attributes must hold unique values. The
only relations that could have empty candidate keys are those with
empty headings, right? (I remember puzzling this when I first
encountered DEE and DUM.) If the heading is not empty, must a
non-empty subset of those attributes be declared as a key?

Because DEE and DUM have no attributes, they can hold no more than
one tuple. If a relation heading contains even a single attribute,
cardinality is boundless -- subject, of course, to any constraints
on values and "physical" limits. In the single-attribute case, the
superkey is irreducible and thus a candidate key. If more attributes
are added, the arity of the candidate key might increase -- but it
will never be less than one. After all: all relation variables have
candidate keys. (I know I made a leap from relations to relation
variables, but Paul did name these in his example.)

Have I missed something?

Identifying the error condition is easy. The problem of identification only arises after you replace the error with DEE or DUM.

Basically, you have a choice: your compiler can stop with an error or your compiler can allow anything by replacing non-existent relvars with an arbitrary constant.

If one has a compiler that translates some user language into an internal language, one can catch most of the errors with it. Then, in the internal representation, once the compiler has established it is not an error, then it must be whatever it is.
.

Relevant Pages

  • Re: No exceptions?
    ... with the confidence that your expressions are still correct. ... I suggest an empty candidate key in a relation with any number of attributes is closer. ... whether one adds one attribute or an arbitrary number of attributes is less important than the fact that the candidate key will have an empty set of attributes. ... While at the UI, I think most people would consider a spelling error an error, I would like, at a very low internal level, to ignore typo's of that sort, evaluate it as written, and give a result that is logically consistent. ...
    (comp.databases.theory)
  • Re: No exceptions?
    ... set of attributes that qualify as a candidate key must hold unique values and no subset of those attributes must hold unique values. ... empty headings, right? ... This table might be the configuration data for an application, for example, containing the one-off constants that parameterize its behaviour. ... In that case, if you ever deleted the configuration data record, all the other tables (that reference it) in the database would be emptied - automatically. ...
    (comp.databases.theory)
  • Re: Relation Schemata vs. Relation Variables
    ... value of a candidate key identifies a tuple regardless of time. ... Perhaps I should have said "relvar that contains a tuple". ... That's probably because it hasn't clicked yet that a transition is a *set* ... however, in the transition {(r, t, empty), }, t and t' ...
    (comp.databases.theory)
  • Re: No exceptions?
    ... have an empty key, regardless of the number of attributes in the ... It follows that such a relvar can have no other keys. ... unique values from the sets of values that comprise superkeys. ... I suppose irreducible key would do just as well, but for historical reasons, candidate key already means an irreducible key. ...
    (comp.databases.theory)