All keys are superkeys. Identifying a candidate key of a relvar is purely a matter of interpretation because it depends on what the intended meaning of the relvar is - except in the special case where the candidate key is the empty set, which is obviously irreducible. Except in the case of the empty set, key constraints in a database are effectively superkey constraints (this incidentally being one criticism of SQL's daft "PRIMARY KEY" constraint - it's really a misleadingly named superkey constraint!).

Of course I agree that you can't necessarily derive candidate keys. Candidate keys must still exist though because every superkey implicitly contains a candidate key. So I don't see what you mean by "not a relational key".

In SQL you can only identify a superkey when there are no nullable columns and when DISTINCT is used. SQL query processors can't and don't assume that. They just don't bother to derive keys at all. Even if they did then the best they could do in many cases would be to assume the whole set of columns is a superkey. The advantage of the relational model is that you can identify smaller keys and more of them, which is much more useful. In decision support queries you normally want to distinguish the dimension attributes from the measures for example. You don't want measure columns to be considered as part of a key.