GATE DA DBMS and SQL Handwritten Notes PDF

These hand-written notes trace DBMS, SQL, normalization and data warehousing for GATE DA as one connected system, moving from a raw table to a clean schema to a query-ready warehouse so students see how each piece feeds the next.

Databases sit in the Programming and Databases block of GATE DA and appear almost every year. Because the topic is procedural, students who understand the pipeline end to end answer faster than those who memorise rules in isolation.

Building the Data Model First

Every database begins with a design decision. These pages start from entities and relationships, then show how that design becomes real tables with keys.

• Entities and attributes map to tables and columns.
• Primary keys uniquely identify each row, while foreign keys link tables together.
• Candidate keys and superkeys set up the functional dependencies you will need for normalization.

Getting the keys right here is what makes the later normalization steps fall into place cleanly.

Writing SQL That the Examiner Expects

GATE tests whether students can read a query and predict its output. The notes work through the clauses in the order the database actually processes them.

• SELECT, FROM, WHERE for basic filtering and projection.
• GROUP BY and HAVING for aggregate questions, a frequent trap.
• Joins, including inner, outer, and self joins, drawn with sample rows.
• Nested and correlated subqueries, where most students slip.

Turning Dependencies Into Normal Forms

Normalization is the heart of this topic. The notes take one messy table and walk it up the normal forms so the reasoning stays visible at each stage.

Functional dependencies drive everything, so students first learn to compute an attribute closure and find candidate keys before applying any rule.

• First normal form removes repeating groups.
• Second and third normal form remove partial and transitive dependencies.
• BCNF tightens the rule so every determinant is a key.

See Normalization Solved on a Board

Source: Piyush Wairale IITM

From Clean Tables to a Data Warehouse

Once the operational schema is normalized, the notes shift to how data is reshaped for analysis, the last stage of the pipeline.

• Star and snowflake schemas and why analytics deliberately denormalises.
• Fact and dimension tables and how they differ from operational tables.
• ETL, the extract, transform, and load flow that fills the warehouse.

Seeing the warehouse right after normalization makes the trade-off clear: normalize to store safely, denormalise to query fast.

Traps That Cost GATE Marks Here

Most lost marks in this topic come from a handful of repeat errors. The notes flag each one where it happens.

• Assuming a table is in BCNF without checking every functional dependency.
• Forgetting that NULL values change how COUNT and joins behave.
• Mixing up which schema denormalises when comparing star and snowflake.
• Skipping the attribute closure and guessing candidate keys.