UGC NET Computer Science & Applications Topic-wise Practice

🗄️

Database Management Systems

Database Management Systems is Unit 4 of the UGC NET Computer Science and Applications syllabus, and it makes three quite different demands. Attribute closures, candidate keys, normal forms and serialisability have to be derived on paper before you can even read the options. SQL questions hand you a schema and four queries that differ by a single clause, so they reward close reading rather than recall. And a thin layer of vocabulary — degree against cardinality, which key is called what — should cost you seconds. Recent papers lean hardest on the first two.

13 sets10 Q per set

Recommended next

View all sets PYQs & full tests

Available Practice Sets

Choose any set, or follow the recommended next set above.

Recommended

Every Database Management Systems question ever asked

137 previous year questions from 2018–2026, each with its options and the correct answer — free to read.

View 137 PYQs

What this topic covers

1The ER model and its notation, the relational model, and mapping an ER diagram onto relations — including weak entities and total participation

2Relational algebra, tuple and domain relational calculus, and the SQL that expresses the same queries

3SQL in detail: joins, subqueries, set membership, aggregation, and the data-definition statements that alter a table

4Keys and integrity constraints — primary, candidate, alternate and foreign — together with views

5Functional dependencies and normalisation from 1NF through BCNF, then on to 4NF and 5NF

6Transaction processing: the ACID properties, conflict and view serialisability, and concurrency control

7Locking protocols including two-phase locking, deadlock handling, and log-based recovery

8File organisation and indexing — dense against sparse indexes, B-trees, B+ trees, and static and extendible hashing

9Distributed databases, data warehousing with its fact and dimension tables, data mining, and NoSQL systems

Key concepts to revise

1Degree is the number of attributes and cardinality the number of tuples — the paper asks this directly and plants the swap in the distractors

2BCNF is stricter than 3NF, never the reverse. A statement asserting that third normal form is stronger is the standard false option in multi-statement questions

3Which dependency each normal form addresses: functional dependencies for 2NF, 3NF and BCNF; multivalued for 4NF; join dependency for 5NF, also called project-join normal form

4The closure shortcut — an attribute that appears on no right-hand side of any functional dependency must belong to every candidate key. The candidate-key questions all open with exactly this step

5A partial dependency, where a non-prime attribute is determined by a proper subset of a candidate key, is what breaks 2NF; a transitive dependency is what breaks 3NF

6Every relation has a lossless, dependency-preserving decomposition into 3NF, but not every relation has one into BCNF — and the question is asked in that direction

7Two operations conflict only when they belong to different transactions, touch the same data item, and at least one of them writes. Two reads never conflict

8Conflict serialisability is settled by drawing the precedence graph and looking for a cycle, not by eyeballing the schedule for a pattern

9A phantom is caused by an insertion changing which rows a repeated range query returns, not by an update or a delete

10IN tests membership in a list of values where a plain equals sign cannot, and DISTINCT is what collapses the duplicate rows a many-to-many table would otherwise return

11Greater than ALL against a subquery is the 'greater than every row' test; a bare greater-than against a subquery returning several rows does not mean the same thing

12Candidate keys are the minimal unique identifiers; whichever one is chosen becomes the primary key and the others are the alternate keys

How to prepare this topic

1Get fast at computing an attribute closure. It is the prerequisite step for both the candidate-key questions and the highest-normal-form questions, and until the dependency set is closed neither is answerable

2Practise reading four near-identical SQL statements and finding the one flaw. Recent papers have given a single university schema and then asked several questions where the options differ only by IN against equals, a missing DISTINCT, ALL against a bare comparison, or ALTER TABLE against ALTER

3Commit the database design sequence to memory — requirement analysis, then conceptual, then logical, then physical. It has appeared as a standalone ordering question in more than one recent paper, with the options differing only in where physical design lands

4For statement-set questions, decide on every statement in isolation before you look at the combinations. They are built so that knowing three of the four still leaves two options standing

5Drill the List-I to List-II format on normal forms, ER notation and concurrency vocabulary. One wrong pairing eliminates the entire option, so partial matching earns nothing

6Bank the definitional recall — degree, cardinality, the key vocabulary, what SQL is for — in bulk and at speed. Those are the marks that buy you the minutes the closure questions will consume

Common mistakes to avoid

1Answering that third normal form is stronger than BCNF. BCNF is the stricter condition, and the reversal is planted deliberately in true-or-false statement sets

2Swapping degree and cardinality, when degree counts the columns and cardinality counts the rows

3Assuming a BCNF decomposition always preserves dependencies. Where a functional dependency has a non-superkey left-hand side that no fragment can keep intact, no lossless BCNF decomposition preserves it

4Blaming the phantom problem on updates, when it is insertions that change the membership of the queried range

5Accepting a query that filters on a column from another table without supplying the join predicate, which yields a Cartesian product rather than the rows asked for

6Stopping a closure computation early and missing an attribute that only becomes derivable once another dependency fires, which yields a candidate key larger than the real one

7Treating 4NF and 5NF as interchangeable — one removes multivalued dependencies and the other join dependencies, and the paper asks for them by name

8Counting SELECT among the data-modifying commands when a question lists it alongside INSERT, DELETE and UPDATE

Frequently Asked Questions

How many questions from Database Management Systems appear in UGC NET Computer Science Paper 2?

NTA publishes no per-unit breakdown. Paper 2 sets 100 questions at 2 marks apiece with nothing deducted for a wrong answer, and this is one of ten units, so expect a handful rather than a fixed count. Because so many of them are computational rather than recalled, it is a unit where preparation converts directly into marks.

Do I need to write SQL queries from scratch?

No, but you do need to read them very closely. The paper is entirely multiple choice, and recent sittings have given a university schema followed by several questions whose four options differ by one clause — IN against an equals sign, a missing DISTINCT, ALL against a bare comparison, ALTER TABLE against ALTER. You are never asked to compose a query, only to identify which one is valid and which one answers the question.

Which part of this unit repeats most often in the paper?

Two parts, in roughly equal measure. Functional dependencies and normalisation — computing candidate keys, identifying the highest normal form a relation already satisfies, and judging whether a decomposition is lossless and dependency-preserving. And SQL, where one schema is typically followed by a cluster of questions. Between them they account for most of the Database Management Systems questions in recent papers.

Is it enough to memorise the normal form definitions?

No. Definition questions do appear — fifth normal form is concerned with join dependency, for instance — but the heavier ones hand you a schema and a set of functional dependencies and expect you to work the answer out. The definitions are where you start, not where you stop.

How much of the data warehousing and NoSQL section is actually asked?

Less than normalisation or SQL, but it is not safe to skip. Recent papers have asked which table holds the central measurable events in a warehouse schema — the fact table, with dimension tables supplying descriptive context — and have used matching questions on the Hadoop ecosystem. A working vocabulary is enough; the depth demanded is nothing like the normalisation questions.