Elementary Key Normal Form¶
Elementary key normal form tests each minimal functional dependency against a key determinant or a target attribute in an elementary key.
Core Idea¶
Elementary key normal form (EKNF) requires that, for each functional dependency X→A whose left side has no dispensable attribute, either X is a candidate key or A belongs to an elementary key. An elementary key itself determines at least one attribute by such a minimal dependency. Zaniolo introduced the condition in 1982; BCNF implies EKNF, which implies 3NF, but the conditions differ.
Scope of Application¶
EKNF helps design relational schemas when intended functional dependencies are known. In Zaniolo's original department–manager–account example, the combined relation is 3NF but fails EKNF and should separate department-manager assignment from account association. His telephone example is EKNF though not BCNF, showing why imposing BCNF can lose direct representation of a dependency. This is a formal design criterion, not a performance benchmark.
Clarity¶
For DA(D#,MGID,ACC#) with D#→MGID and MGID→D#, the keys are (D#,ACC#) and (MGID,ACC#). All attributes are key attributes, so 3NF passes. Yet D#→MGID is elementary, D# is not a key for DA, and MGID is in no elementary key: EKNF fails. For TEL(AREA,NUMBER,PLACE) with (AREA,NUMBER)→PLACE and PLACE→AREA, the first determinant is an elementary key, so AREA qualifies as an elementary-key attribute and TEL passes EKNF despite failing BCNF.
Manages Complexity¶
The test catches a 3NF relation like DA that repeats a basic manager assignment across many account rows, while keeping room for TEL's direct constraint representation. A BCNF split of TEL into (PLACE,AREA) and (PLACE,NUMBER) no longer embodies (AREA,NUMBER)→PLACE directly in Zaniolo's account. Stronger separation is not automatically better when an FD must remain represented.
Abstract Reasoning¶
State semantic FDs, compute candidate keys, identify single-target dependencies with minimal determinants, then identify elementary keys and test each dependency. Do not infer FDs from current rows or confuse an SQL unique constraint with a minimal key. If the FD assumptions change, recompute the normal form.
Knowledge Transfer¶
The method transfers to other relational domains only when their actual dependencies have the same structure. Its test presupposes a Database Schema with intended functional dependencies; EKNF is not itself every schema. A product (Id,Type) implementation example is not a valid elementary-key demonstration if Id→Type, because that pair is not a minimal candidate key. The broader design lesson—balance anomaly separation and dependency representation—can travel, but EKNF itself remains a relational FD test.
Relationships to Other Abstractions¶
Current abstraction Elementary Key Normal Form Domain-specific
Parents (1) — more general patterns this builds on
-
Elementary Key Normal Form presupposes Database schema Domain-specific
EKNF presupposes a database schema and its dependencies.
Hierarchy path (1) — routes to 1 parentless root
- Elementary Key Normal Form → Database schema → Symbolic Representation → Representation → Abstraction
Neighborhood in Abstraction Space¶
Elementary Key Normal Form sits in a sparse region of the domain-specific corpus (68th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Property Ontology & Code Smells (18 abstractions)
Nearest neighbors
- Keyspace (distributed data store) — 0.84
- GI (complexity) — 0.84
- Data Class — 0.83
- GI-complete — 0.83
- Propositional logic — 0.83
Computed from structural-signature embeddings · 2026-10-08