Normalization Questions in GATE CSE: Keys, 3NF, BCNF

Normalization questions in GATE CSE are never definition questions. You are given a relation, a set of functional dependencies, and asked to compute something: how many candidate keys, which normal form, whether a decomposition is lossless. Every one of those reduces to attribute closure. Learn to run closure quickly and accurately and this entire topic becomes mechanical.

Key takeaways

• Attribute closure is the only tool you need. Keys, normal forms and losslessness are all closure computations wearing different clothes.
• An attribute that appears on no right-hand side is in every candidate key. An attribute that appears on no left-hand side is in no candidate key.
• Prime means it belongs to some candidate key. 3NF forgives a bad determinant when the dependent is prime; BCNF does not.
• A binary decomposition is lossless when the common attributes determine one of the two fragments completely.
• BCNF decomposition is always lossless but may lose a dependency. 3NF synthesis gives you both.

Where this sits in the paper

The official syllabus line for Section 9 lists "Integrity constraints, normal forms" and nothing more specific, so the whole of functional dependency theory has to be read into those four words. Third-party analyst compilations put Databases at roughly 4 to 11 marks per paper across 2009 to 2026, averaging near 6.9. The 2009 to 2017 window averages about 6.6 and the 2018 to 2026 window about 7.2, so the direction is flat rather than rising. These counts are unofficial and analysts disagree by two or three marks because borderline questions get classified differently. Syllabus wording and paper structure can change, so check the current notification before planning around any of this.

Within Databases, functional dependencies and normal forms sit in the top group along with SQL and transactions. One analyst listed the 2026 shift-1 Databases topics as SQL, normalization and transactions. The full ranking inside the subject is in the DBMS important topics guide, and the cross-subject view is in the subject-wise weightage breakdown.

Closure, done fast

The closure of a set X under F is everything X determines. Start with X, scan the FD list, and whenever a left-hand side is fully inside your current set, add its right-hand side. Repeat until a full pass adds nothing.

Two habits save time. Stop the moment the closure contains all attributes, without finishing the pass, and skip any FD whose right-hand side is already inside the set.

Finding candidate keys without guessing

Take this relation, which is small enough to hold in your head:

R(A, B, C, D, E)
F = { AB -> C,  C -> D,  D -> B,  E -> A }

Classify the attributes first. E appears on no right-hand side, so E is in every candidate key. No attribute is absent from both sides here. A, B, C and D all appear on both sides, so any of them may or may not be in a key.

Now start from the mandatory core and grow it:

So R has three candidate keys: EB, EC and ED. The prime attributes are B, C, D and E. Only A is non-prime.

Two things to notice. Adding A to E gained nothing, because A never triggers an FD on its own. And once EB, EC and ED are confirmed as keys, no larger set containing them needs checking, which keeps the work down to five closures instead of thirty-one subsets.

This is the step where questions eat time. If you enumerate subsets in size order without first fixing the mandatory core, a two-mark item can cost six minutes. Writing the two attribute lists, left-hand sides and right-hand sides, before touching any closure is worth more than any shortcut formula.

The normal form ladder

Decide the normal form by testing each non-trivial FD in F against the candidate key list.

Apply it to the relation above. The keys have size two, so their proper subsets are the single attributes E, B, C and D. The FD E to A has a proper subset of the key EB on the left and the non-prime attribute A on the right. That is a partial dependency, so R is in 1NF only. It never reaches 2NF, and there is no point testing 3NF or BCNF.

Four shortcuts that resolve a lot of one-mark statement questions:

• Any relation with two attributes is in BCNF.
• If every attribute is prime, the relation is automatically in 3NF, though possibly not BCNF.
• If every candidate key is a single attribute, the relation is automatically in 2NF.
• A relation in 3NF whose candidate keys are all single attributes is also in BCNF.

The 3NF versus BCNF gap

The whole difference is one clause. Consider:

R(P, Q, S)
F = { PQ -> S,  S -> P }

PQ is a key. SQ is also a key, since S gives P and Q is already there. So P, Q and S are all prime. Every FD now has a prime attribute on the right, and the relation is in 3NF. But S to P has a determinant whose closure is only SP, not a superkey, so BCNF fails.

That is the shape to memorise: a relation is in 3NF but not BCNF exactly when some FD has a non-superkey determinant and a prime dependent. Statement questions that claim "every 3NF relation is in BCNF" are testing this one relation in disguise.

Lossless join and dependency preservation

For a decomposition of R into two fragments R1 and R2, the test is short. Compute R1 intersect R2, take its closure, and check whether it contains all of R1 or all of R2. Either side is enough. If it contains neither, the decomposition is lossy and joining the fragments back produces spurious tuples.

Decompose the second example on its violating FD into R1(S, P) and R2(S, Q). The common attribute is S, and S determines P, so S determines all of R1. Lossless.

Now check dependency preservation. The FDs that survive on R1 are S to P. On R2 there is nothing non-trivial, because Q is determined by nothing. The union is just S to P, and the closure of PQ under that single FD is PQ, which does not give S. The dependency PQ to S has been lost. To enforce it after the split you would have to join the fragments on every insert.

That is why the two properties are stated separately. BCNF decomposition is always lossless and sometimes not dependency preserving. 3NF synthesis from a minimal cover is always both, because every FD of the cover gets a relation containing all of its attributes.

Two details catch people. The test above is valid only for a binary decomposition; for three or more fragments you need the tableau chase. And when you project FDs onto a fragment, project the closure of F, not just the FDs you were given, or you will miss dependencies that hold through an intermediate attribute.

The traps in one list

• An attribute on no right-hand side is forced into every key; an attribute on no left-hand side is excluded from every key.
• Enumerating all subsets instead of starting from the forced core is the main time sink.
• Prime means "in some candidate key", not "in the primary key".
• 2NF only concerns non-prime attributes and proper subsets of keys, so a relation whose attributes are all prime cannot violate it.
• 3NF is rescued by a prime dependent; BCNF is not. That single clause is the whole gap.
• Losslessness needs the intersection to determine one side fully, not partially.
• Do not assume a BCNF decomposition preserves dependencies; check it separately.
• Super key counting is 2 to the power n minus k for one key of size k, with inclusion and exclusion when keys overlap.
• A minimal cover is computed by splitting right-hand sides first, then removing extraneous left-hand attributes, then removing redundant FDs, in that order.

The cross-subject version of this list is in common mistakes that cost marks in GATE CSE, and the closure, super key and decomposition rules in compact form are in the GATE CSE formula sheet.

How to practise

Build one relation of five or six attributes with four FDs, at least one of them cyclic, and reuse it. Find the candidate keys, list the prime attributes, decide the normal form, then decompose it two ways and test both for losslessness and preservation. Change one FD and redo the chain. Ten minutes on the same relation with small edits teaches more than ten unrelated problems, because you see exactly which change moves it from BCNF to 3NF.

Then time yourself. A candidate key count on five attributes should take under three minutes, a normal form decision under two. If you are slower, the bottleneck is almost always that you are not fixing the forced attributes first. The method for choosing which topics deserve this drilling is in the guide to what the evidence says about important questions, and the Databases chapter of the GATE CSE 2027 book carries a full question bank on closures, key counting and decomposition with worked solutions.