Second Normal Form¶
A first-normal-form relation schema is in second normal form when every non-prime attribute depends fully on every candidate key.
Core Idea¶
Second normal form (2NF) is a property of a relation schema under stated functional dependencies. It holds when the schema is in first normal form (1NF) and every non-prime attribute—one belonging to no candidate key—is fully functionally dependent on every candidate key. Full dependence means no proper subset of the key already determines that attribute. A single partial dependency on any candidate key makes the schema fail.[1]
The word every matters. A designated primary key is only one candidate key. Codd's R4 has a singleton primary key but fails 2NF because a non-prime attribute depends on part of an alternate composite candidate key. The form is a pass/fail test of a schema and its dependencies; a decomposition is a possible response to failure, not the definition of passing.[1]
Structural Signature¶
Signature: a 1NF relation schema + its functional dependencies + all candidate keys + its non-prime attributes → an all-key full-dependence verdict.
- Relation schema and dependency assumptions. Attribute names and declared or established functional dependencies define what can be inferred across valid relation states. A row snapshot alone cannot establish the all-states property.[1]
- Candidate-key set. Each candidate key is a minimal identifier. The test includes alternate keys even if one key was chosen as primary. Omitting a composite alternate can turn a failure into a false pass.[1]
- Non-prime test class. Only attributes outside every candidate key enter Codd's full-dependence clause. If none exist, that clause is vacuous; 1NF is still required.[1]
- Full-dependence rule. For each non-prime attribute and each candidate key, ask whether a proper subset of that key already determines the attribute. One such subset is enough to fail.[1]
- Verdict. The result classifies the whole schema under the stated dependencies. A storage redesign, anomaly observation or choice of primary key is not itself a 2NF verdict.[1][2]
What It Is Not¶
2NF is not a method that necessarily splits a table. Codd shows that a violating relation may be projected into relations that pass, and IBM demonstrates such a split for warehouse stock, but the normal form itself is the condition those resulting schemas satisfy. It is not a promise that no redundancy, insertion problem or update problem remains. Those may motivate normalization, while 2NF rules out a specific kind of partial-key dependency.[1][2]
It is also not a primary-key-only check. Codd explicitly constructs an alternate-key counterexample. Nor is it third normal form (3NF): Codd's additional 3NF condition addresses non-prime attributes that depend transitively on a candidate key. A schema can pass 2NF while failing that further test.[1]
Scope of Application¶
Apply the test to a relational schema when its 1NF status, candidate keys and relevant functional dependencies can be established. This includes conceptual database design before implementation and analysis of a documented table design. The result depends on the dependency assumptions; inspecting a finite sample of stored rows may suggest a partial dependency, but the sample alone cannot establish whether that dependency holds across all valid relation states or whether the schema passes 2NF.[1]
A composite primary key is not required for the rule to matter: a composite alternate candidate key can fail it. If all candidate keys are singleton, no proper nonempty subset can determine a non-prime attribute by the usual full-dependence test; after 1NF, the clause is then automatic. This is a boundary of the test rather than a reason to omit alternate keys.[1]
Clarity¶
When a design repeats supplier city across supplier–part rows, distinguish the dependency that creates the failure from its effects. In Codd's T(S#,P#,SC), supplier number S# determines supplier city SC although the relation's key is (S#,P#). That partial dependency fails 2NF. Repeated SC values and possible anomalies explain why the failure may matter; they are neither needed to identify the dependency nor sufficient by themselves to prove it.[1]
The same distinction prevents a false pass when a surrogate or designated primary key is short. First enumerate all candidate keys; then classify prime and non-prime attributes; only then run the full-dependence test. Codd's R4 exposes the error in reversing that order.[1]
Manages Complexity¶
The condition compresses many possible rows and update histories into a small schema-level check. Instead of testing every imagined insertion or deletion, determine the functional dependencies, compute all candidate keys, identify non-prime attributes, and check every key–attribute pair for a proper-subset determinant. For a failing pair, the subset and dependent attribute pinpoint a possible decomposition target.[1]
This reduction does not automatically choose a repair or prove its join is lossless. Codd's T projection has that property under his stated dependencies; another design needs its own dependency and join analysis. The verdict likewise does not decide whether denormalization is useful for a particular workload.[1]
Abstract Reasoning¶
Given a proposed relation, establish 1NF and a justified functional-dependency set. Derive every candidate key rather than accepting only the declared primary key. Mark the attributes that occur in no candidate key. For each such attribute A and each candidate key K, ask whether some proper subset of K determines A. If so, the relation is not in 2NF; if no such pair exists, it passes under those assumptions.[1]
This procedure explains both positive and negative cases. Codd's R3 passes even though it has the composite alternate key (S#,P#,J#): its only non-prime attribute Q depends on the whole triple, and its other candidate key X# is singleton. Codd's R4 fails because supplier city depends on S#, a proper subset of that alternate triple, even though X# remains a singleton primary key.[1]
Knowledge Transfer¶
The same test applies literally to Codd's formal supplier/part/project relation and to IBM's documented part-at-warehouse stock design: schema, dependencies, candidate keys, non-prime attributes and proper-subset dependence are mapped in each. The application changes from a formal relation to an administrative database example, while the all-candidate-key rule stays fixed.[1][2]
Outside relational schemas, a component determining an outcome while another component is irrelevant can be an analogy for redundancy. It is not literally 2NF without relational attributes, functional dependencies and candidate keys. The broader Predicate Prime names the portable idea of a truth-valued condition; it does not transfer database normal forms to arbitrary systems.
Examples¶
Codd's R3 supplier–part–project relation. In R3(X#,S#,P#,J#,Q), X# and (S#,P#,J#) are candidate keys. Q is the only non-prime attribute. Codd specifies that Q depends on the whole supplier–part–project triple, not a proper subset, and concludes that R3 is in 2NF.[1]
Mapped back: schema and assumptions → R3 with Codd's listed dependencies; candidate-key set → X# and the composite triple; non-prime test class → Q; full-dependence rule → Q needs the full triple and is fully dependent on singleton X#; verdict → pass. The singleton key does not exempt the alternate composite from examination.[1]
IBM part stock after warehouse-address separation. IBM's DB2 guide starts with part, warehouse, quantity and warehouse address in a combined relation, where address depends on warehouse alone. Its documented split gives PART_STOCK(PART,WAREHOUSE,QUANTITY) and WAREHOUSE(WAREHOUSE,WAREHOUSE_ADDRESS), both presented as 2NF relations.[2]
Mapped back: schemas and assumptions → the two post-split relations and the guide's stated dependencies; candidate-key set → the documented (PART,WAREHOUSE) stock key and singleton WAREHOUSE address key; non-prime test class → QUANTITY and WAREHOUSE_ADDRESS, respectively; full-dependence rule → quantity is a fact of the pair while address is fully dependent on its singleton key; verdict → each resulting relation passes in this documented design. IBM explains the chosen-key example; Codd's every-candidate-key definition remains the general rule.[2][1]
Structural Tensions¶
The sources do not establish an intrinsic optimization tradeoff in the 2NF condition: under fixed schema and dependencies it either holds or fails. A designer may choose to store repeated warehouse addresses for a workload, but that operational choice does not change the schema's dependency verdict. The useful diagnostic question is whether the design goal is to classify the schema or to choose a physical layout; only the first is answered by 2NF.[2]
Structural–Framed Character¶
The identity is structurally sharp within relational database design: unlike supplier/project and part/warehouse carriers use the same all-candidate-key test. It has little evaluative weight by itself; passing is not a universal performance or quality guarantee. Human practice supplies schemas and dependency assumptions and can choose among designs, but a declared relation's verdict follows the rule rather than institutional recognition. The form originated in a research and design tradition, yet no particular institution confers 2NF status. Its vocabulary travels loosely into talk about “removing redundancy”; that metaphor does not meet the relational test. The portable inherited skeleton is Predicate, a condition evaluated as true or false of an object, while candidate keys and functional dependencies keep this named form in databases. Importing the 2NF label into nonrelational workflows would discard its recognition rule. Its character: a domain-specific schema property with a precise logical test, not a substrate-independent normal-form Prime.[1]
Structural Core vs. Domain Accent¶
The skeletal relation is a truth-valued condition on an object, inherited from Predicate. The domain-bound mechanism is the 1NF relational schema with all candidate keys, non-prime attributes and full functional dependence. Remove those and the named 2NF condition disappears. Supplier numbers, part names, warehouse addresses, a chosen primary key and a particular decomposition are case accents.[1][2]
The two examples differ in notation and purpose but remain relational schemas. They do not establish that “2NF” itself applies across unlike substrate classes, so this entry remains domain-specific. Broader dependency-based classification might be a future Prime question only after independent cross-domain evidence; no such node or edge is asserted here.
Instantiates / Related Primes¶
This entry is a kind of Predicate.
The staged strict Second Normal Form → Predicate subsumption edge records the genus-and-differentia relation: a 2NF determination is a predicate on a relational schema. Dependency names a functional relation used inside the test; Constraint can describe an imposed design requirement; neither is the whole property. Third Normal Form is a neighboring, stricter database normal form, not an upward parent. Its current live entry has a separate draft DAG claim; that claim is not imported into this entry's edge.[1]
Relationships to Other Abstractions¶
Current abstraction Second Normal Form Domain-specific
Parents (1) — more general patterns this builds on
-
Second Normal Form is a kind of Predicate Prime
Second normal form is a truth-valued property of a relation schema under stated functional dependencies.The live Predicate Prime is a condition that can be true or false of an object. Second normal form tests a relation schema and its functional dependencies: it is true exactly when first normal form holds and every non-prime attribute is fully dependent on every candidate key. The relational carrier and full-dependence rule add stable differentia; general predicates need not concern databases. The dependency is an input to this predicate, and decomposition is a possible repair, neither its genus.
Neighborhood in Abstraction Space¶
Second Normal Form sits in a sparse region of the domain-specific corpus (89th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Unclustered & Miscellaneous (2551 abstractions)
Nearest neighbors
- Essential Tuple Normal Form — 0.82
- Elementary Key Normal Form — 0.81
- Third normal form — 0.80
- Fourth Normal Form — 0.80
- Relational database — 0.79
Computed from structural-signature embeddings · 2026-10-08
Not to Be Confused With¶
A partial functional dependency is the reason for a failure, not a positive 2NF instance. A lossless projection is a possible repair, not the verdict. Observed duplicate values in a data sample do not by themselves establish a functional dependency. A singleton primary key does not settle the result if an alternate composite candidate key exists. And 3NF asks an additional question about transitive non-key dependence after 2NF.[1][2]
References¶
[1] E. F. Codd, Further Normalization of the Data Base Relational Model, IBM Research Report RJ909 (1971), original author text reproduced by a third party. Especially §§1.2–1.3 (candidate keys), 2.1 (T and lossless projections), 2.2–2.5 (R3, R4 and full dependence), and 3.3 (3NF). The reproduction is used for its original report text; it is not an IBM-hosted scan. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t ↩u ↩v ↩w ↩x ↩y
[2] IBM, DB2 Administration Guide, Planning, Chapter 7, “Logical Database Design,” printed pp. 98–100 (PDF zero-index pp. 113–115), Tables 9–12. Original PDF title: DB2 Administration Guide: Planning. Official guide's part/warehouse worked example uses designated-key wording; it does not replace Codd's all-candidate-key definition. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h