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) is Carlo Zaniolo's 1982 condition on the functional dependencies (FDs) of a relational schema. An FD X→A is elementary when A is not already in X and no proper subset of X determines A. A candidate key is elementary if it is the determinant of at least one elementary FD. A relation is EKNF when, for each elementary FD X→A, either X is a candidate key of the relation or A belongs to an elementary key. Zaniolo proves the containment BCNF ⊂ EKNF ⊂ 3NF in the sense of normal-form implication; his two original schema examples show why the inclusions are strict.[1]
The important word is elementary, not just key. Third normal form (3NF) lets a nonkey determinant survive whenever the dependent attribute belongs to some candidate key. EKNF permits that exception only when the attribute belongs to an elementary key. Boyce–Codd normal form (BCNF) permits no such exception. This places EKNF between 3NF's leniency and BCNF's possible loss of direct dependency representation after decomposition.[1]
Structural Signature¶
Sig role-phrases:
- Relation and declared FD semantics: attributes plus the dependencies that are meant to hold in every admissible instance, not merely a few observed rows.
- Minimal determinant:
XinX→Amust have no proper subset still determiningAto make the FD elementary. - Elementary key membership: a key must itself determine some attribute through an elementary FD; its member attributes can qualify as exceptional targets.
- EKNF admission test: for every elementary FD, require a whole-key determinant or an elementary-key target.
- Constraint representation: when redesigning relations, ask which original FDs the resulting keys and schemas can express directly.[1]
Each role is load-bearing. Without semantic FDs, a table snapshot cannot establish the normal form. Without testing determinant minimality, ordinary implied FDs can obscure the criterion. Replace elementary-key membership with any-key membership and the distinguishing EKNF test becomes the 3NF test; remove the exception and it becomes BCNF.[1]
What It Is Not¶
EKNF is not a table's possession of a SQL UNIQUE constraint, nor a rule that every column or every unique combination is an elementary key. A candidate key is minimal for determining all attributes; a superkey with an extra column is not a candidate key. Even a candidate key may be non-elementary if none of the FDs it determines is elementary. Zaniolo's telephone example has exactly that distinction between two candidate keys.[1]
A glasses-order illustration refers to a product identifier paired with product type to enforce a typed foreign key. That may be a useful implementation constraint, but if Id→Type, the pair (Id,Type) is not minimal as a candidate key and cannot itself witness the paper's definition. The two fully specified DA and TEL examples in Zaniolo's original paper are used rather than promoting a unique-index implementation trick into an EKNF proof.[1]
Scope of Application¶
EKNF applies to relational schema design when functional dependencies and their intended semantics have been identified. It helps decide when a 3NF relation should be split and when enforcing BCNF would sacrifice representation of a dependency within the decomposed schema. Zaniolo argues that Bernstein's synthesis procedure, previously known to generate 3NF schemas, actually produces EKNF relations; the claim is a formal result about that algorithm and FD representation, not an empirical assertion that EKNF databases perform faster.[1]
The normal form does not address every possible source of redundancy: multivalued dependencies, join dependencies, application logic, null behavior, physical indexes and transaction costs lie outside the stated FD criterion. Nor can a few current rows prove an FD. The designer must state that, for example, each manager badge identifies a department in every valid state, and then reason from that constraint.[1]
Clarity¶
Let DA(D#, MGID, ACC#) record a department number, its manager's badge and an associated account. Zaniolo assumes D#→MGID and MGID→D#: one manager corresponds to one department. An account may be shared, so neither department nor manager alone determines ACC#. The candidate keys are (D#,ACC#) and (MGID,ACC#). Because every attribute appears in a candidate key, a 3NF rule permits the relation. But D#→MGID has a minimal determinant D#, which is not a key of DA, and MGID belongs to no elementary key. Thus DA fails EKNF. The analogous reverse FD also fails. Splitting into DA1(D#,MGID) and DA2(D#,ACC#) records the one-to-one assignment and the department-account association separately.[1]
Contrast TEL(AREA,NUMBER,PLACE). Its stated FDs are (AREA,NUMBER)→PLACE and PLACE→AREA. The first determinant is a key and is elementary; hence AREA is an elementary-key attribute. The second FD has a nonkey determinant, PLACE, but its target AREA satisfies EKNF's exception. TEL is EKNF though not BCNF. In this example, the other candidate key (PLACE,NUMBER) does not define an elementary FD merely by determining AREA: PLACE already determines AREA, so the pair is not minimal for that target.[1]
Manages Complexity¶
Normal forms compress many possible duplicate rows and updates into a rule about dependencies. In DA, repeating department-manager correspondence on each account row creates a need to coordinate changes; the relation's all-prime-attribute 3NF status misses that design issue. The EKNF condition catches it because no elementary key licenses the nonkey determinant. Zaniolo's split embodies the manager mapping in one relation and the account association in another.[1]
TEL shows the other side of compression. A BCNF decomposition into TEL1(PLACE,AREA) and TEL2(PLACE,NUMBER) represents PLACE→AREA but not (AREA,NUMBER)→PLACE in the same direct key-based manner. Keeping TEL and adding TEL1(PLACE,AREA) represents both dependencies in Zaniolo's account, while tolerating TEL's non-BCNF form. EKNF is therefore not simply a command to maximize splitting; it is a criterion designed around both separation and representation.[1]
Abstract Reasoning¶
Start from the complete intended FD set, not from an arbitrary data sample. Compute closure to identify candidate keys. For each nontrivial single-target FD X→A, ask whether a proper subset of X still determines A; if not, it is elementary. Identify which candidate keys appear as determinants of at least one such elementary FD. Then test every elementary FD: its determinant must be a key, or its target must be part of one of those elementary keys.[1]
For DA, D#→MGID is elementary but fails both alternatives; all attributes being in some key only establishes the weaker 3NF property. For TEL, PLACE→AREA fails the key-determinant alternative but passes because AREA is part of (AREA,NUMBER), which determines PLACE elementarily. Zaniolo also gives an equivalent test over all nontrivial FDs using a superkey determinant or elementary-key target. The elementary-FD version makes the conceptual reason more visible.[1]
Knowledge Transfer¶
The test transfers to other relational schemas only after their FDs are explicitly modeled. Swapping department and account labels for instructor and course labels does not preserve the result unless the same dependency structure actually holds. This is why a casual course-scheduling analogy is not presented as a source-backed EKNF example. A typed foreign-key arrangement likewise must not be confused with a minimal-key claim.[1]
More abstractly, EKNF illustrates a design compromise: strong local separation can undermine direct representation of global constraints. That lesson may inform schema design discussions, but the specific elementary-key exception is a theorem in relational FD theory. Importing the term into a different kind of graph or data store without relational keys and FDs would be analogy, not another instance of this normal form.[1]
Examples¶
DA: 3NF passes, EKNF refuses¶
In Zaniolo's department-account relation, a department may have many accounts and an account may be shared, while department number and manager badge determine one another. The two compound candidate keys each add the account number. Because every attribute is a key attribute, ordinary 3NF admits DA, yet D#→MGID is elementary and neither EKNF route holds: D# is not a key for all DA attributes, and MGID is not in an elementary key. Zaniolo decomposes the original relation into DA1(D#,MGID) and DA2(D#,ACC#) so manager assignment is represented once and account association separately. This is an original worked failure and repair, not a claim about a measured production database.[1]
Mapped back: relation/FD semantics are DA and the two reciprocal manager FDs; minimal determinant is D# (and reciprocally MGID); elementary key membership is absent in DA; the EKNF test therefore fails; the constraint-representation remedy separates manager mapping from account association. If account actually determined department, the key structure would change and this conclusion would need recomputation.
TEL: EKNF permits a non-BCNF relation¶
In Zaniolo's regional telephone list, area code plus number identifies place, while place identifies area code. For TEL(AREA,NUMBER,PLACE), (AREA,NUMBER)→PLACE passes through its key determinant. PLACE→AREA has a determinant that is not a key, so BCNF rejects TEL, but EKNF accepts it because AREA belongs to elementary key (AREA,NUMBER). Zaniolo explains that a BCNF-only split into (PLACE,AREA) and (PLACE,NUMBER) fails to represent the first FD directly; a schema retaining TEL alongside (PLACE,AREA) represents both. The example shows the permitted exception's design purpose, not that non-BCNF redundancy is free.[1]
Mapped back: the relation/FD semantics are TEL's two declared dependencies; their determinants are minimal; (AREA,NUMBER) supplies elementary-key membership to AREA; the EKNF test passes both FDs but the BCNF test fails the second; constraint representation explains why the simpler BCNF pair is not equivalent for Zaniolo's objective. If place no longer determined area, this exception would no longer be the same case.
Structural Tensions¶
Anomaly separation versus dependency representation. Splitting a relation more aggressively can avoid repeated facts, as DA's manager mapping illustrates. Yet a BCNF decomposition of TEL can make an original FD unavailable as a directly embodied key constraint across its two component relations. Keeping a non-BCNF TEL relation preserves a route to that constraint but leaves a design cost that strict separation sought to remove. EKNF narrows 3NF's exception to an elementary-key target: it rejects DA and tolerates TEL. This is an actual two-sided schema-design cost, not merely the statement that one normal form is stricter. Diagnostic: after a proposed split, can each intended FD still be represented without reconstructing a join or adding an external assertion, and what repeated facts remain?[1]
Structural–Framed Character¶
EKNF lies nearer the structural end of the spectrum than most institutional entries: once relation attributes and FDs are fixed, its admission rule is formal and determinate. Still, there is human-practice dependence upstream. Designers decide which semantics really hold, which constraints must be represented, and whether a model of the world merits a given FD. Its evaluative weight is technical rather than moral: Zaniolo favors both reduced redundancy and dependency representation, a design objective rather than a theorem that all implementations are improved.[1]
The term originated in relational database research and its vocabulary travels only with that machinery. An SQL uniqueness declaration may be one implementation aid but does not alone prove candidate-key minimality or all semantic FDs. Calling a non-relational data structure 'EKNF' because it has a minimal-looking identifier would import a label, not recognize the same test. In a newly modeled relational domain, however, the same FD/elementary-key reasoning can genuinely recur. Its character: a formally specified, domain-bound schema criterion whose abstract tradeoff can be compared elsewhere, while the named identity remains relational.[1]
Structural Core vs. Domain Accent¶
The skeleton is minimal dependency → key-or-qualified-target test → accept or redesign a relation while checking constraint representation. Its domain mechanism is relational FD closure, candidate-key computation and schema decomposition. The D#/MGID and AREA/PLACE names are accents: replacing them with other attributes preserves the result only if the dependency graph is preserved.[1]
The named EKNF entry fails the prime bar because it cannot be detached from relational attributes, FDs and the special elementary-key criterion without becoming a generic constraint-design maxim. It presupposes the live Database Schema identity and its intended constraints, but is not itself a schema or a subspecies of all schemas. A possible future prime might articulate representation-versus-separation across many systems. The live Third normal form is a comparator, not a verified strict parent.
Instantiates / Related Primes¶
This entry presupposes Database schema.
Strict compositional prerequisite: Database schema (presupposes, strict). EKNF tests a relational schema under intended functional dependencies, whereas many schemas are not EKNF and need not undergo this test. The live Third normal form remains adjacent by logical implication, not an unreviewed graph edge; EKNF is not interchangeable with 3NF or BCNF, and elementary keys are not all candidate keys.
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.Its elementary-key test needs a relational schema and intended functional dependencies; schemas need not satisfy or be evaluated for EKNF.
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
Not to Be Confused With¶
An elementary dependency is minimal in its determinant for its target; an elementary key is a key that determines at least one target by such a dependency. A candidate key need not be elementary. “Key attribute” in a 3NF test includes membership in any key; “elementary-key attribute” in EKNF is narrower. Finally, EKNF is a property of a relation under intended FDs, not an empirical property inferred from today's rows.[1]
References¶
[1] Carlo Zaniolo, “A New Normal Form for the Design of Relational Database Schemata,” ACM Transactions on Database Systems 7(3), 1982, 489–499, author-hosted original paper, especially DA/TEL examples pp.492–494, EKNF Definition 3 and Lemma 5 p.495, schema-synthesis Theorems 1–2 pp.496–497 (accessed 2026-10-02). registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t ↩u ↩v ↩w