Zero2Dataengineer

Zero2Dataengineer

Share this post

Zero2Dataengineer
Zero2Dataengineer
Normalization vs Denormalization
Zero to DE Daily Lessons

Normalization vs Denormalization

Schema Design is a Superpower

Avantikka_Penumarty's avatar
Avantikka_Penumarty
May 07, 2025
∙ Paid

Share this post

Zero2Dataengineer
Zero2Dataengineer
Normalization vs Denormalization
Share

Welcome back to Zero2DataEngineer!


Today, we go deeper into how schema design can either streamline your data pipeline… or turn it into a spaghetti monster. we unpack how your database schema shapes everything — speed, cost, logic, scalability.

And no, it’s not just theory.

Good schema = fast queries, fewer bugs, and easier handovers.
Bad schema = JOIN hell, duplication drama, and angry dashboards.

Zero2Dataengineer is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.


What’s the Difference?



Normalization Forms (Real-World Style)

1NF – First Normal Form

  • Rule: Atomic columns, no repeating groups

  • Think of it like: Every drawer in your closet holds only one type of item

  • Example:
    Bad: Phone Numbers = 123, 456
    Good: Separate rows per number

2NF – Second Normal Form

  • Rule: 1NF + all columns depend on entire primary key

  • Think of it like: No room for half-relevant details

  • Example: Don't include Student Name in a table where the primary key is (Student_ID, Course_ID)

3NF – Third Normal Form

  • Rule: 2NF + no transitive dependencies

  • Think of it like: No gossip. Columns shouldn't depend on other non-key columns.

  • Example: Move Department_Location to a separate Departments table instead of placing it in Employees.


Real Life Scenarios

Fintech Use Case: Normalized Schema (OLTP)

Let’s say you're working at a fintech startup on a banking system. You separate:

  • Customer Table → updated rarely

  • Accounts Table → moderate frequency

  • Transactions Table → updated constantly

Why this works: Different update rates + data integrity + modular ETL pipelinesYour transactional system handles:

  • Customers

  • Accounts

  • Transactions

Instead of storing everything in one big table, you normalize:

  • One table for customer details

  • Another for account info

  • A third for transactions

Why?
Because each table changes at different speeds and scales. Transactions update constantly. Customers, rarely. This improves storage, indexing, and update reliability.

UPGRADE TO ANNUAL SUBSCRIPTION

This post is for paid subscribers

Already a paid subscriber? Sign in
© 2025 Avantika
Privacy ∙ Terms ∙ Collection notice
Start writingGet the app
Substack is the home for great culture

Share