Re: No exceptions?

J M Davitt wrote:
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?

No. A relation can have an empty set as its primary key, in which case that relation is constrained to have at most one row of data. This table might be the configuration data for an application, for example, containing the one-off constants that parameterize its behaviour. Things like the corporation name, US federal tax ID number, state of registration, etc.

Further, any other relation could reference the configuration data relation via a foreign key with an on delete cascade action. 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.

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@xxxxxxxxxxxxx, jleffler@xxxxxxxxxx
Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/
.

Relevant Pages

  • Re: No exceptions?
    ... 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. ... 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. ... your compiler can stop with an error or your compiler can allow anything by replacing non-existent relvars with an arbitrary constant. ...
    (comp.databases.theory)
  • 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?
    ... 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)
  • 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: Partial reconfiguration using ICAP
    ... clock cycles after the configuration data to empty it's internal ... pipeline. ...
    (comp.arch.fpga)