Re: No exceptions?

Jonathan Leffler wrote:
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.

Thanks, Jonathan; this is useful. From it I understand that the
way to ensure that a relvar is a singleton is to declare an empty
key

VAR singleton RELATION { ... } KEY {}

and the fragment declaring the constraint would look like:

FOREIGN KEY {} REFERENCES singleton


Jon Heggland wrote:
> There is some confusion here on both parts, I think. Any relvar can
> have an empty key, regardless of the number of attributes in the
> relvar. It follows that such a relvar can have no other keys. A
> relvar has a set of (candidate, if you will, but I consider that
> term meaningless) keys, in general, but this set cannot be empty
> ---there is always at least one key.

I understand your point about candidate keys; I believe the term
is used to distinguish the irreducible set of attributes that hold
unique values from the sets of values that comprise superkeys.

The rest of your post confuses me. I understand that the last
sentence refers to a set of keys, but I'm not sure how it is that
there is only one key in that set of keys if that key's set of
attributes is empty. It seems to me that every attribute would be
a key and every combination of attributes would be a superkey. I
don't see how an empty attribute key precludes other keys.
.

Relevant Pages

  • Re: No exceptions?
    ... set of attributes that qualify as a candidate key must hold unique ... empty headings, right? ... only one value for them if it had an 'empty' set of candidate keys, ... regardless of the number of attributes in the relvar. ...
    (comp.databases.theory)
  • Re: No exceptions?
    ... All the attributes in a relation comprise, at least, a superkey. ... 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? ... I thought a relation with any number of attributes could have only one value for them if it had an 'empty' set of candidate keys, eg. a relation that has only one tuple? ...
    (comp.databases.theory)
  • Re: No exceptions?
    ... All the attributes in a relation comprise, at least, a superkey. ... 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? ... I thought a relation with any number of attributes could have only one value for them if it had an 'empty' set of candidate keys, eg. a relation that has only one tuple? ...
    (comp.databases.theory)
  • Re: No exceptions?
    ... empty headings, right? ... only one value for them if it had an 'empty' set of candidate keys, ... regardless of the number of attributes in the relvar. ...
    (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. ... "Every attribute" would also be a superkey. ...
    (comp.databases.theory)