Database Normalization Study Guide: 1NF to 6NF in 32 SQL Flashcards
Study database normalization with 32 real flashcards: anomalies, keys, functional dependencies, 1NF to BCNF, 4NF-6NF, plus the worked example the deck lacks.
Studying. But it's also a video game. 🎮
Flashcards, quizzes and games that make you actually remember.
Posted by
FLIP IT TeamRelated reading
Database Normalization in German: 32 Flashcards from 1NF to BCNF and 6NF
Learn database normalization in German: 32 flashcards on anomalies, keys and 1NF to 6NF, with IHK exam terms like Einfügeanomalie and two cards to rewrite.
Database Normalization in Spanish: 32 Flashcards from 1FN to FNBC and 6FN
Study database normalization in Spanish: 32 flashcards on anomalies, keys and 1FN to 6FN, with tips on Spanish exam terms and the one card to rewrite.
Learn Database Normalization in French: 32 Flashcards from 1NF to 6NF
French edition of Flip It's normalization deck: anomalies, keys, 1NF to 6NF, Merise vocabulary for 2NF and 3NF, and the one card you should rewrite before revising.
Normalization is the part of database design that interviewers love and textbooks bury in notation. Flip It deck NC9223 – SQL: Database Design & Normalization squeezes it into 32 cards, from the three update anomalies to the obscure forms (EKNF, ETNF, DKNF) that most courses never mention.
Study this deck: SQL: Database Design & Normalization
1 / 10Database normalization
Tap the card for the answer · swipe right if you knew it, left if not
What the cards actually say
| Front | Back |
|---|---|
| Insertion anomaly | Certain facts cannot be recorded unless other unrelated data is also recorded, often requiring nulls |
| Deletion anomaly | Deleting one fact forces you to delete a completely different fact |
| First Normal Form (1NF) | Scalar columns, no duplicate rows, no nested records or sets of values |
| Second Normal Form (2NF) | Every non-prime attribute depends on the whole of each candidate key |
| Transitive functional dependency | A → B → C, where B is not a key |
| Boyce-Codd Normal Form (BCNF) | Every non-trivial functional dependency begins with a superkey |
| Sixth Normal Form (6NF) | The primary key plus at most one other attribute |
| Denormalization | Deliberately adding redundancy to speed up queries |
| According to C.J. Date, when is a database truly normalized? | Only in 5NF |
Notions covered
Data redundancy, data integrity, update/insertion/deletion anomalies, functional dependency, multivalued dependency, join dependency, lossless decomposition, primary key, composite key, candidate key (minimal superkey), superkey, prime vs non-prime attributes, 1NF, 2NF, 3NF, EKNF, BCNF, 4NF, ETNF (2012), 5NF, DKNF, 6NF, denormalization, columnar storage, OLTP vs data warehouse, Codd's goal for 1NF (a data sub-language grounded in first-order logic).
How to study this deck
Learn the keys first. Cards 13-16 (primary, composite, candidate, superkey) come after the normal forms, yet 2NF, 3NF and BCNF are all defined in their terms. Move them to the front, and add one card the deck never states: a prime attribute is one that belongs to some candidate key. Without it, card 7's precise 3NF definition (dependencies must start with a superkey or end with a prime attribute) is unreadable.
Write the worked example the deck is missing. Not one card decomposes an actual table. Take one OrderLines(order_id, product_id, quantity, product_price, customer_name, customer_city) table keyed on (order_id, product_id) and write five cards: why it breaks 2NF (price depends on product_id alone, the customer on order_id alone), the 2NF split into Products, Orders and OrderLines, the transitive dependency left in Orders (order_id → customer_name → customer_city), the final 3NF schema, and the join that rebuilds the original (lossless decomposition, card 30). The abstract definitions stick far better once they point at a table you built.
Prioritise. Card 25 says it outright: beyond 4NF is mostly academic. For interviews and real schemas, 1NF → BCNF plus denormalization is the core; tag EKNF, ETNF, DKNF and 6NF as "theory" and review them less often.
Two cards to rewrite
- Card 11 (5NF) ends with "preventing lossless decomposition issues", which inverts the idea. Better: every non-trivial join dependency is implied by the candidate keys, so the table cannot be split further without losing information.
- Card 28 calls columnar storage "an internal 6NF representation". Column stores borrow the one-attribute-per-structure idea, but they are a physical storage layout, not a normal form; keep the analogy, drop the equivalence.
Once the schema is clean, practise querying it with SQL queries, joins and aggregates, and compare with the non-relational models in NoSQL and the 4 database types.
Find NC9223 – SQL: Database Design & Normalization in the library on Flip It.
Ready to learn faster? 🚀
Join FLIP IT for free and turn studying into a game.