Is every candidate key a superkey?

Yes. It is a superkey with no unnecessary attributes.

Is every superkey a candidate key?

No. Some superkeys contain removable attributes.

Does a duplicate-free sample prove a schema-level superkey?

No. The combination must identify records in every instance allowed by the modeled rules.

AI Glossary / Data engineering and architecture / Advanced

Superkey

Definition

A superkey is a set of attributes whose combined values uniquely identify a tuple in every permitted instance of a relation. It may contain attributes that are unnecessary for uniqueness. A candidate key is a minimal superkey: removing any attribute from it would lose the required identifying property. The concept concerns the rules of the data model, not merely the absence of duplicates in today's sample.

What it means

To identify a record reliably, a system needs a rule that distinguishes it from every other permitted record. Sometimes one attribute is sufficient; sometimes several are needed together. Adding further attributes to an identifying set does not make it cease to identify the record, but the enlarged set may be redundant. For a business team, the important question is what combinations are guaranteed to remain unique as valid data changes. A small spreadsheet can suggest possibilities, yet it cannot establish that a combination will remain unique under all the organization's allowed situations.

How it works

Modelers start from the intended constraints and determine which attribute sets identify whole records. They then check minimality when seeking candidate keys. In a SQL implementation, declared constraints provide concrete enforcement, but SQL details require care. PostgreSQL documents that a primary key enforces uniqueness and non-null values, while the treatment of nulls in unique constraints differs according to configuration and database behavior. A theoretical key argument therefore needs to be translated into appropriate implementation rules. A column label such as ID, or a query returning no duplicates once, is not itself that enforcement.

Three practical examples

A learning platform checks whether an enrollment is identified by a learner-offering pair or whether repeated attempts require another attribute.
A data integration team tests whether a source identifier must be combined with a source-system identifier to avoid collisions.
An AI feature pipeline reviews its join fields to ensure that a supposedly identifying combination cannot match several entity records.

Think of it this way

Imagine a numbered locker system in one building. If each locker number is unique within that building, number plus paint color still identifies the locker, but the color adds nothing to identification. Across several buildings, the building name may become necessary. The analogy emphasizes that uniqueness depends on the defined domain and rules, rather than on how distinctive a label happens to look.

Worked example

Consider an original relation Enrollment(Learner, Offering, Status). Define the rule that a learner may have at most one enrollment in a particular offering, while each learner can join several offerings and each offering can have several learners. Under these assumptions, {Learner, Offering} is a superkey. Neither attribute alone is sufficient, so the pair is also a candidate key. {Learner, Offering, Status} is another superkey, but not a candidate key because Status can be removed. Example rows (L1, C1, active), (L1, C2, active) and (L2, C1, pending) illustrate why the single attributes can repeat. If repeated attempts within the same offering become valid, the original pair no longer provides the intended identification without a revised model, such as distinguishing attempts explicitly.

Illustrative case study

In a fictional content-service integration, two source systems both assign the identifier 17 to different records. A prototype joins data using the identifier alone and combines unrelated descriptions. The team revisits the domain and adopts the source-system plus local-identifier combination for this integration, after confirming the relevant uniqueness rules within each source. It then tests collision cases and preserves provenance in generated outputs. The scenario shows why the scope of an identifier matters. It does not claim that a composite key automatically solves every entity-matching problem: two source records may still represent the same real-world subject and require a separate reconciliation process.

Common misconceptions and mistakes

A superkey need not be minimal; a candidate key must be. Minimal also does not mean globally shortest: different candidate keys can have different numbers of attributes, provided none contains a removable attribute while remaining a key. Another mistake is treating uniqueness in one extract as a permanent business rule. Missing values and inconsistent normalization can further complicate SQL implementations. Finally, a superkey is not an access credential or encryption key. It identifies records within the modeled relation; it does not authorize a user to read or modify them.

Business use

The concept supports reliable record identification, integration and database design. Ask who guarantees an identifier's scope and whether valid future events can repeat the proposed combination. For an AI application, these questions affect feature joins, document updates and the attribution of generated answers to source records. Record the identification assumptions beside the implementation constraints, and revisit them when the business process changes. A key that was appropriate for one enrollment per offering may be inappropriate after repeat attempts are introduced. Good identification design reduces ambiguity but does not establish that every recorded fact is correct.

Check your understanding

Why is Learner alone insufficient in the toy relation?

Answer: One learner can join several offerings.

Why is the three-attribute set not a candidate key?

Answer: Status can be removed without losing identification under the stated rules.

What change invalidates the original pair as the intended key?

Answer: Allowing multiple attempts for the same learner and offering without distinguishing those attempts.

Related terms

Candidate key
Primary key
Composite key
Functional dependency
uniqueness constraint
relational schema

Learn next

Define a fictional relation and write its uniqueness rules in ordinary language. Propose one minimal identifying set and one redundant identifying set. Construct examples showing why each attribute in the minimal set is needed, then describe a business-rule change that would require revisiting your conclusion. Check separately how null values would be handled in the intended database.

Business rule

Sources

Silberschatz, Korth and Sudarshan, Database System Concepts, Relational Model slides hosted by Cornell University, key definitions: https://www.cs.cornell.edu/courses/cs230/2001sp/DSC_3.pdf PostgreSQL documentation, Constraints: https://www.postgresql.org/docs/current/ddl-constraints.html The enrollment example, locker analogy and integration scenario are original educational illustrations. Their conclusions depend on explicitly stated business rules; SQL null behavior is not assumed to be identical across products.

Previous: Superiority and inferiority ranking method Next: Superpixels