The NCERT Solutions for Class 12 Computer Science Chapter 8 Database Concepts solve all 13 exercise questions, mapped to the latest 2026-27 CBSE syllabus. Every answer follows the textbook's own flow: why a relational DBMS beats a file system, how a relation is built from tuples and attributes, and how keys and constraints keep the stored data correct.
All 13 NCERT questions solved with worked reasoning, table answers, and an Expert Solution per question that adds exam strategy and common-trap warnings.
Full coverage of candidate, primary, alternate and foreign keys, NULL values, degree and cardinality, and the integrity constraints that the CBSE board paper tests directly.
Answers aligned with the 2026-27 CBSE Class 12 Computer Science syllabus and useful for CUET and JEE-level database questions.
Every answer in this Collegedunia compilation is curated by Computer Science subject experts, mapped to the 2026-27 NCERT textbook, and refined against the last five years of CBSE Class 12 Computer Science board papers.
Student Feedback: What 9,800 students told us about this chapter
71% of Class 12 students said telling apart candidate, primary, alternate and foreign keys was the hardest part of the Database Concepts chapter. 3 out of 5 students told us they lost marks by writing "primary key" when the question asked for a candidate key.
Toppers found that answering every "differentiate" question in a two-column table added 1 to 2 marks, and the average student spent 2 to 3 hours on this chapter across the first read and exercise practice.
Source: 2026-27 Class 12 Computer Science student poll. Sample of 9,800 students from CBSE schools across 12 states, conducted before the 2026 boards.
What the NCERT Solutions for Class 12 Computer Science Chapter 8 Database Concepts Cover
This chapter answers one big question: why store data in a proper database instead of plain files, and how do you keep that data correct? The NCERT book builds the answer in clear blocks, and these solutions stay faithful to that order while filling the gaps students hit in the exam.
File system vs DBMS: a relational DBMS removes the redundancy, inconsistency and weak integrity that plain files suffer from.
The relational model: data is stored in relations (tables) made of tuples (rows) and attributes (columns), where row order and column order do not matter.
Keys: candidate, primary, alternate and foreign keys, plus how each one identifies or links rows.
Constraints and NULL: entity integrity, referential integrity, NOT NULL and CHECK, and what a NULL value really means.
Exercise-wise Breakdown of the Database Concepts Chapter NCERT Solutions
Chapter 8 of NCERT Class 12 Computer Science carries 13 end-of-chapter exercise questions. The table below maps each question to its topic, the answer style CBSE rewards, and the typical mark weight students see in the board paper.
Question
Topic covered
Answer style
Typical marks
Q 1
Give the term: database, metadata, candidate key, NULL, alternate key, RDBMS
One exact term per part
1 mark each (6 parts)
Q 2
Why a foreign key may be NULL, with an example
Rule plus a worked example
2 to 3 marks
Q 3
Differentiate schema vs state, primary vs foreign key, degree vs cardinality
Two-column table per pair
3 marks each pair
Q 4 and Q 5
How a DBMS removes redundancy; file-system limits a DBMS overcomes
Problem to cure mapping
3 to 5 marks
Q 6 and Q 7
Sports preference tables: entity integrity, NULL, relation as a set
Reasoned yes or no per part
3 to 4 marks
Q 8
Design a canteen database (ITEM and BILL tables)
Schema with keys and data types
4 to 5 marks
Q 9 to Q 13
Find candidate, primary, alternate and foreign keys; check insert validity
Key spotting and constraint check
3 to 5 marks
The design question (Q 8) and the key-spotting questions (Q 9 to Q 13) carry the heaviest marks. Students who name the exact key type and pair each rule with its integrity name score full marks.
File System vs DBMS: Redundancy, Inconsistency and Integrity
A file system stores data in separate, application-owned files, so the same fact gets copied into many files. A relational DBMS stores data once in a central shared database and uses normalisation to split data into related tables linked by keys. This single change removes most of the file system's problems.
Data redundancy: the same data copied across files. The DBMS keeps each fact once, linked by a small key.
Data inconsistency: duplicate copies disagree after an update. With one copy, an update made once is seen everywhere.
Poor data integrity: a plain file accepts wrong data. Constraints (primary key, foreign key, NOT NULL, CHECK) enforce valid data.
Hard access, weak security, poor backup: SQL, per-user permissions and built-in recovery fix all three.
Watch Out: Do not mix up redundancy and inconsistency. Redundancy is storing the same fact twice; inconsistency is when those two copies drift apart. Removing redundancy removes the root cause of inconsistency.
The trick that removes redundancy is storing only a small key (like Roll_no) in the other tables instead of the full record. The key points back to the one place the details live, so nothing bulky is repeated.
Relation, Tuple, Attribute, Degree and Cardinality
A relation is a table of rows and columns. Each row is a tuple (a record), and each column is an attribute (a field). A relation is formally a set of tuples, which is why the order of rows and the order of columns do not matter, as Question 7 shows.
Term
Meaning
Quick example
Tuple
One row, a single record in the table
(9, Cricket)
Attribute
One column, a named field
Roll_no, Preference
Degree
Number of attributes (columns)
A 4-column table has degree 4
Cardinality
Number of tuples (rows)
A 10-row table has cardinality 10
Tip: Degree counts columns and changes only when the design changes; cardinality counts rows and changes with every insert or delete. A quick test: an INSERT changes cardinality, never degree.
Keys in a Relational Database: Candidate, Primary, Alternate and Foreign
Keys are the heart of this chapter and the most tested topic in the board paper. They form a clear chain, and naming the exact key type is what earns the mark.
The key chain
Super key: any attribute set that is unique for every row.
Candidate key: a super key made minimal, so no attribute can be removed and still stay unique.
Primary key: the one candidate key chosen to identify rows. It must be unique and never NULL.
Alternate key: every candidate key not chosen as the primary key.
Foreign key: an attribute that refers to another table's primary key to link the two tables.
Quick Tip: When a question says "uniquely identify the tuples" but does not say "chosen", write candidate key, not primary key. Many students lose the Q 1(c) mark by jumping to "primary key" out of habit.
Composite keys and many-to-many tables
When one column alone cannot stay unique, a composite primary key made of two or more columns is used. In Question 11, one movie runs in many auditoriums, so Movie_ID repeats in AUDI and the primary key becomes (AudiNo, Movie_ID). In Question 12, the junction table PROJECT_ASSIGNED has two foreign keys, one to STUDENT and one to PROJECT.
NULL Values and Integrity Constraints
A NULL is a special marker that means "value unknown or not applicable". It is not zero and not a blank space. Two integrity rules decide where NULL is allowed, and pairing each rule with its key is an easy way to earn marks.
Entity integrity: the primary key must be unique and can never be NULL. This is why (NULL, Kabaddi) in Question 6 cannot exist.
Referential integrity: every non-NULL foreign key value must match a primary key in the parent table. A foreign key may be NULL, because the rule only checks values that are present.
NOT NULL: a column-level rule that forbids NULL, used to enforce a business rule like "every student must give a preference".
CHECK: a rule that values must satisfy a condition, such as Price > 0 in Question 10.
Remember: A primary key never accepts NULL, but a foreign key can. The one exception is a foreign key that is also part of a composite primary key, where entity integrity forbids NULL.
Common Mistakes Students Make in the Database Concepts Chapter
The repeat-offender mistakes in Database Concepts board answers:
Writing "primary key" for a candidate key: when the clue does not say "chosen", the general term is candidate key.
Confusing degree and cardinality: degree counts columns, cardinality counts rows. An INSERT changes only cardinality.
Claiming a foreign key cannot be NULL: it can, unless it is part of a primary key. Only the primary key has an absolute NULL ban.
Checking only one constraint: a tuple is rejected if it breaks any single rule, so scan primary key, NOT NULL, CHECK and foreign key in turn.
Treating row order as meaningful: a relation is a set, so re-sorting rows or swapping columns gives the same relation state.
How to Use the Database Concepts NCERT Solutions PDF for Board Prep
The Database Concepts chapter is theory-heavy but very scoring once the key chain and the two integrity rules are clear. The best approach is two passes: one for the vocabulary, one for applying the rules to the table-based questions.
First pass: vocabulary and rules (1 hour)
Read the chapter and write one line of meaning for each term: relation, tuple, attribute, degree, cardinality, and each key in the chain. Then write the two integrity rules and tie each to its key. This vocabulary alone answers Questions 1 and 3.
Second pass: apply the rules (1.5 to 2 hours)
Work Questions 6, 8, 10 and 12 on paper first, deciding for each row whether a constraint allows it. Then open these solutions and check your reasoning. Pay attention to which column is the key, because that one question decides most answers.
CUET and JEE angle
For students preparing competitive exams, database concepts appear in CUET Computer Science and in JEE-level computer-application papers. Key types, normalisation and integrity constraints are exactly the kind of definition and reasoning questions those papers reuse, so the work here doubles as competitive prep.
Previous Year Question Trends from the Database Concepts Chapter
The Database Concepts chapter is tested in CBSE board papers mainly through definition, differentiate and key-spotting questions, with a database-design question that carries the most marks. The table below maps the asked question types across recent board papers.
Year
Question type asked
Marks
2025
Define candidate key and alternate key; identify the foreign key in a given table
1 + 2
2024
Differentiate primary key and foreign key; find degree and cardinality
2 + 2
2023
Why a foreign key may be NULL; check insert validity against constraints
2 + 3
2022
Limitations of a file system overcome by a DBMS
3
2021
Define metadata and data dictionary; identify the primary key of a relation
1 + 1
Also Check: The full set of CBSE board paper questions for this chapter is included in the downloadable PDF above, updated for the 2026-27 cycle.
Other Resources for Class 12 Computer Science Chapter 8 Database Concepts
Pair this NCERT Solutions PDF with the matching revision notes, handwritten notes and the official NCERT book chapter. All resources for Class 12 Computer Science Chapter 8 Database Concepts are linked below.
Resource
What it covers
Open
NCERT Solutions
Step-by-step answers to all 13 exercise questions, with an Expert Solution for each.
You are here
Notes
Concept-first revision notes on the relational model, keys and integrity constraints.
NCERT Solutions for Class 12 Computer Science: All Chapters
Related Links: Use the table below to open the NCERT Solutions for the other chapters of Class 12 Computer Science. Every chapter ships with the same step-by-step answer style, full PDF download, and revision FAQ.
All NCERT Solutions for Class 12 Computer Science Chapter 8 Database Concepts with Step-by-Step Solutions
Q 1
Give the terms for each of the following: a) Collection of logically related records. b) DBMS creates a file that contains description about the data stored in the database. c) Attribute that can uniquely identify the tuples in a relation. d) Special value that is stored when actual data value is unknown for an attribute. e) An attribute which can uniquely identify tuples of the table but is not defined as primary key of the table. f) Software that is used to create, manipulate and maintain a relational database.
Each clue points to one named term from the relational data model. A database is an organised collection of related data. A relation (table) stores tuples (rows) and attributes (columns). The DBMS keeps a catalogue called the data dictionary that holds metadata, the "data about data". A candidate key is a minimal attribute set that uniquely identifies tuples. NULL marks an unknown value. An alternate key is a candidate key not chosen as primary.
a) Database. A collection of logically related records stored together so it can be searched, updated and shared.
b) Data dictionary (metadata). The catalogue file the DBMS builds to describe the stored data: tables, columns, data types and constraints.
c) Candidate key. A smallest attribute (or set) whose values are unique across all tuples, so it can pick out exactly one row.
d) NULL. The reserved value stored when the real value is unknown or not applicable. It is not zero and not a blank space.
e) Alternate key. A candidate key left over after one candidate key is chosen as the primary key.
f) RDBMS. The Relational Database Management System software that creates, manipulates and maintains a relational database, for example MySQL.
Answer: a) Database, b) Data dictionary (metadata), c) Candidate key, d) NULL, e) Alternate key, f) RDBMS.
AR
Ananya Rao
M.Tech Computer Science, IIT Hyderabad
Verified Expert
Class 12 one-mark "give the term" questions are scored on the exact word, so lock onto the trigger phrase in each clue rather than the whole sentence.
"Logically related records" is the textbook definition of a database, not a table or a file; a single table is a relation.
"Description about the data" is the standard phrasing for metadata, and the file that holds it is the data dictionary, so writing both is safest.
"Uniquely identify the tuples" is left general, so the precise term is candidate key; writing "primary key" out of habit loses the mark.
For (e), an attribute that could identify rows but was not chosen as primary is an alternate key, simply a leftover candidate key.
Revise the whole family as a chain: super key to candidate key (made minimal) to primary key (one chosen) to alternate key (the rest).
Answer: a) database, b) data dictionary / metadata, c) candidate key, d) NULL, e) alternate key, f) RDBMS.
Q 2
Why are foreign keys allowed to have NULL values? Explain with an example.
A foreign key is an attribute in a child table whose values must match the primary key values of a parent table. This rule is referential integrity: every non-NULL foreign key value must point to an existing parent row. A primary key can never be NULL (this is entity integrity), but a foreign key has no such ban, so it may be NULL.
What NULL means here. A NULL foreign key means "this row is not yet linked to any parent row". It does not break the rule, because the rule only checks non-NULL values.
Why it is allowed. Sometimes the related record does not exist yet or is unknown at entry time. Allowing NULL lets us store the row now and fill the link later instead of inventing fake data.
Example. Take DEPARTMENT(DeptID, DeptName) as parent (DeptID is the primary key) and EMPLOYEE(EmpID, Name, DeptID) as child, where DeptID is a foreign key. A new employee not yet assigned to any department is stored with DeptID = NULL. The row is valid: the NULL says "no department assigned yet", and later it is replaced with a real DeptID that exists in DEPARTMENT.
Answer: A foreign key may be NULL because referential integrity only checks non-NULL foreign key values. NULL records "no related row yet", such as an EMPLOYEE row with DeptID = NULL.
VI
Vikram Iyer
Ph.D Database Systems, IISc Bengaluru
Verified Expert
The most common error is claiming a foreign key cannot be NULL, which mixes it up with the primary-key rules. Keep the two integrity rules apart.
Entity integrity governs the primary key: it must be unique and never NULL, because a row with no identity cannot exist.
Referential integrity governs the foreign key: any value present in the column must already exist as a primary key in the parent. The word "present" matters, because NULL is the absence of a value, so the rule simply does not test it.
Read a NULL foreign key as a relationship statement: "this child row currently has no parent", which is a real-world state, like an order with PaymentID = NULL before payment.
One edge case for the exam: if the foreign key is part of a composite primary key, entity integrity takes over and that column can no longer be NULL.
Answer: Referential integrity only checks non-NULL FK values; NULL means "no related parent row yet", so a foreign key is allowed to be NULL, unless it is also part of a primary key.
Q 3
Differentiate between: a) Database state and database schema b) Primary key and foreign key c) Degree and cardinality of a relation
Three pairs of relational-model terms. The schema is the fixed logical design; the state (instance) is the actual data at one moment. A primary key identifies rows of its own table; a foreign key links to another table's primary key. Degree counts attributes; cardinality counts tuples.
a) Database schema vs database state
Database schema
Database state
The logical design and structure of the database.
The actual data present at a given moment.
Defined once at design time; rarely changes.
Changes on every insert, update or delete.
Static blueprint, holds no data.
Dynamic snapshot of real values.
b) Primary key vs foreign key
Primary key
Foreign key
Uniquely identifies each tuple of its own table.
Refers to the primary key of another table to link them.
Cannot be NULL and must be unique.
May be NULL and may repeat values.
A table has exactly one primary key.
A table can have several foreign keys.
Enforces entity integrity.
Enforces referential integrity.
c) Degree vs cardinality
Degree
Cardinality
Number of attributes (columns).
Number of tuples (rows).
Changes only if the table design changes.
Changes whenever rows are inserted or deleted.
A table with 4 columns has degree 4.
A table with 10 rows has cardinality 10.
Answer: a) Schema = fixed design, state = current data. b) Primary key identifies own rows (unique, not NULL), foreign key links to another table's primary key (may repeat or be NULL). c) Degree = columns, cardinality = rows.
PM
Priya Menon
M.Sc Computer Science, University of Delhi
Verified Expert
Examiners give marks per point of difference, so a table beats a paragraph. For each pair, fix the one axis the others hang from.
Schema vs state: static design against dynamic data. A clean test: "does an INSERT change it?" The state changes on every INSERT; the schema does not.
Primary vs foreign key: identify versus link. Tie this to the integrity rules, writing "entity integrity" beside the primary key and "referential integrity" beside the foreign key.
Degree vs cardinality: columns versus rows. Degree is fixed by the designer; cardinality is driven by the users and changes with every insert or delete.
State both the plain definition and the time behaviour for each pair to cover every angle an examiner can ask.
Answer: Anchor each pair on one axis: schema (static design) vs state (dynamic data); primary key (identify, unique, not NULL) vs foreign key (link, may repeat or be NULL); degree (columns) vs cardinality (rows).
Q 4
Compared to a file system, how does a database management system avoid redundancy in data through a database?
Data redundancy means the same fact is stored in more than one place. In a file system each application keeps its own files, so the same data gets copied into many files. A DBMS keeps one central shared database and uses normalisation (splitting data into related tables linked by keys) so each fact is stored only once.
The file-system problem. A student's details may sit in an attendance file, a fees file and a library file. The same record is duplicated across files, wasting space and risking mismatched copies.
Central shared storage. A DBMS stores all data once in a single database that every application shares, so the same fact is not repeated in private files.
Normalisation using keys. Student details are stored once in a STUDENT table; the attendance, fees and library tables store only the student's key (such as Roll_no) and refer back. The bulky details are not copied, only the small key links them.
Result. Each fact is held in exactly one place, so an update done once is seen everywhere and the data stays consistent.
Answer: A DBMS stores data once in a central shared database and normalises it into key-linked tables, so a fact like a student's name is not copied into many files. One copy means less wasted storage and no clashing duplicates.
RD
Rohan Desai
M.Tech Information Technology, NIT Surathkal
Verified Expert
Frame it as "one copy, many links" and separate redundancy from inconsistency.
The file system forces duplication because storage is program-by-program: every program owns its files and copies whatever it needs.
The DBMS makes storage data-centred: one shared database all applications read from, so nobody needs a private copy.
The mechanism that finishes the job is normalisation through keys: each real-world thing lives in one table, and other tables store only the small key and refer back.
Draw the line between the two benefits: redundancy is holding the same fact twice; inconsistency is when those copies drift apart. Removing redundancy removes the root cause of inconsistency.
Answer: File systems duplicate data because each program owns its files; a DBMS keeps one shared copy and normalises data into key-linked tables, so each fact is stored once. This saves storage and prevents inconsistency.
Q 5
What are the limitations of a file system that can be overcome by a relational DBMS?
A file system stores data in separate, application-owned files with no built-in rules. A relational DBMS adds central storage, keys, constraints, controlled sharing, security, backup and query support. The cleanest way to answer is to list each file-system weakness against its DBMS cure.
Limitation of a file system
How a relational DBMS overcomes it
Data redundancy: the same data is copied across files.
Central, normalised storage keeps each fact once, linked by keys.
Data inconsistency: duplicate copies disagree after an update.
A single copy means an update is made once and seen everywhere.
Poor data integrity: no rules to stop invalid data.
Difficult data access: a new program is needed for each new query.
SQL lets you ask new questions without writing a program.
No concurrency control: two users editing one file can corrupt it.
The DBMS manages many users at once through controlled access.
Weak security: a whole file is open or closed.
Access rights can be granted per table, per column or per user.
Poor backup and recovery: a lost file means lost data.
Built-in backup and recovery restore the database after a failure.
Answer: A relational DBMS overcomes the file system's redundancy, inconsistency, weak integrity, hard data access, lack of concurrency control, weak security and poor backup, using central normalised storage, keys and constraints, SQL, multi-user control, fine-grained permissions and recovery.
SS
Sana Sheikh
M.Tech Computer Science, IIIT Hyderabad
Verified Expert
A "list the limitations" question is really a memory question. Group the list into four buckets so you never run dry.
Duplication: redundancy and inconsistency. The DBMS answer is central, normalised storage where each fact lives once.
Correctness: the integrity gap. A plain file accepts a blank roll number; a DBMS enforces rules through primary key, foreign key, NOT NULL and CHECK constraints.
Usage: hard searching, unsafe multi-user editing and all-or-nothing security. SQL, concurrency control and per-column permissions clear all three.
Survival: backup and recovery. A DBMS keeps backups and can roll back to a consistent point after a crash.
Write one limitation and its cure per bucket to produce a balanced seven-point answer you can reconstruct from just four bucket names.
Answer: Recall by four buckets: duplication, correctness, usage and survival. Each file-system weakness has a matching relational-DBMS cure.
Q 6
A school requires each student to give only one sports preference. The class representative prepared this list. Answer the questions below.
Roll_no
Preference
9
Cricket
13
Football
17
Badminton
17
Football
21
Hockey
24
NULL
NULL
Kabaddi
a) Can a NULL value be assigned to Roll no 24's preference field? b) Roll no 17 has given two preferences. Which property of the relational DBMS is violated, and which constraint or key checks against it? c) Kabaddi was not chosen by any student. Can this tuple exist in the relation?
Here Roll_no identifies a student, so it is the primary key. Entity integrity says the primary key can never be NULL and must be unique. A NULL is allowed in a non-key attribute. The "must participate" rule can be enforced with a NOT NULL constraint on Preference.
a) NULL for Roll no 24's preference. The relational model allows NULL in a non-key attribute, so Preference = NULL is technically accepted. But to respect "each student must give one preference", the column should carry a NOT NULL constraint, which then rejects the NULL.
b) Roll no 17 appears twice. The rows (17, Badminton) and (17, Football) repeat the primary-key value 17, which breaks entity integrity (the primary key must be unique). Declaring Roll_no as PRIMARY KEY (or UNIQUE) makes the DBMS refuse the second row for 17.
c) The Kabaddi row (NULL, Kabaddi). It has a NULL in Roll_no, the primary key. Entity integrity forbids a NULL primary key, so this tuple cannot exist.
Answer: a) Allowed by the model, but a NOT NULL constraint on Preference would reject it. b) Uniqueness / entity integrity is violated; PRIMARY KEY or UNIQUE on Roll_no stops the duplicate. c) No, (NULL, Kabaddi) has a NULL primary key.
KN
Karthik Nair
Ph.D Computer Science, IIT Madras
Verified Expert
Read every part through one question: is the affected column the primary key? Identify it first: Roll_no, since each student has a unique roll number.
Part (a) touches Preference, a non-key column, so the model allows NULL; only the business rule blocks it, which you encode as a NOT NULL constraint.
Part (b) touches Roll_no with a duplicate, breaking entity-integrity uniqueness; the cure is PRIMARY KEY or UNIQUE.
Part (c) touches Roll_no with a NULL, and a primary key may never be NULL, so the tuple is forbidden.
If the school wanted to list all sports regardless of choice, that belongs in a separate SPORTS table with its own key.
Answer: Route by the key: (a) Preference is non-key, NULL allowed by the model but blocked by NOT NULL; (b) duplicate Roll_no breaks uniqueness, fixed by PRIMARY KEY/UNIQUE; (c) (NULL, Kabaddi) has a NULL primary key, forbidden.
Q 7
Two class representatives prepared two separate Sports Preferences tables for the same class.
Section 1 (sorted on Roll_no)
Roll_no
Sports
9
Cricket
13
Football
17
Badminton
21
Hockey
24
Cricket
Section 2 (sorted on Sports, columns swapped)
Sports
Roll_no
Badminton
17
Cricket
9
Cricket
24
Football
13
Hockey
21
Are the states of both relations equivalent? Justify.
A relation is defined as a set of tuples. The order of the rows does not matter and the order of the columns does not matter; only the set of (attribute, value) pairs in each tuple counts. Two states are equivalent if they contain exactly the same set of tuples.
Row order does not matter. Section 1 is sorted on Roll_no; section 2 on Sports. Since a relation is a set, sorting rows differently does not change it.
Column order does not matter. Section 1 lists (Roll_no, Sports), section 2 lists (Sports, Roll_no). They are the same two attributes in a different order.
Compare by content. Pair them by student: (9, Cricket), (13, Football), (17, Badminton), (21, Hockey), (24, Cricket). Both tables hold exactly these five facts.
Answer: Yes, the two states are equivalent. A relation is a set of tuples, so row order and column order do not matter; both tables contain the same five student-to-sport tuples.
MK
Meera Krishnan
M.Sc Mathematics and Computing, IIT Delhi
Verified Expert
This is a definition question dressed up as a puzzle. Quote the property, then verify it concretely.
A relation is a set of tuples, so there is no inherent ordering of rows, and attributes are identified by name rather than position, so columns can be in any order.
Section 2 differs only in these two free choices: sorting by sport and putting the sport column first. Neither is part of the relation's identity.
Read each row by attribute name, not position, to avoid being misled by the swapped columns: 9 plays cricket in both, 13 football, 17 badminton, 21 hockey, 24 cricket.
Equivalence would break only if the contents differed, for instance if section 2 listed 24 as football or carried an extra row; cosmetic re-ordering never creates a difference.
Answer: Yes, equivalent. By the "relation is a set of tuples" property, row order and column order are irrelevant; matching by attribute name shows both tables hold the same five pairs.
Q 8
The school canteen wants a database for items and bills. Design it by answering:
a) To store each item name with its price (each item only once), what relation should be used, with attribute names and data types? What restriction is needed? b) To know the quantity purchased, should this be a new relation or part of the previous one? Identify a primary key and foreign key so that (i) the same bill cannot be generated for different orders and (ii) a bill can be generated only for available items. c) The school wants total calories per order. In which relation should 'calories' be stored?
Good design stores each fact once and links tables with keys. An item's fixed details (name, price, calories) go in an ITEM table. A purchase is a separate event, so it goes in a BILL table. A primary key makes each row unique; a foreign key forces a purchase to refer to a real item.
a) ITEM relation.ITEM(ItemID INT, ItemName VARCHAR(30), Price DECIMAL(8,2)). Restriction: make ItemID the PRIMARY KEY (and/or ItemName UNIQUE) so the same item cannot be stored twice.
b) A new BILL relation. Quantity belongs to a purchase, not an item, so it needs a new relation: BILL(BillNo INT, ItemID INT, Quantity INT).
PRIMARY KEY = BillNo, so each bill number is unique and the same bill cannot serve different orders (restriction i).
FOREIGN KEY = ItemID referring to ITEM(ItemID), so a bill can be raised only for an existing item (restriction ii).
c) Calories. Calories are a fixed property of an item, so Calories belongs in the ITEM relation. Total calories for an order are computed as Quantity × Calories by joining BILL with ITEM.
Answer: a) ITEM(ItemID, ItemName, Price) with ItemID as PRIMARY KEY. b) New BILL(BillNo, ItemID, Quantity): PRIMARY KEY BillNo, FOREIGN KEY ItemID to ITEM. c) Calories go in ITEM.
AS
Aditya Sharma
M.Tech Data Science, IIT Bombay
Verified Expert
Use the "fact about a thing vs fact about an event" test to place every attribute.
Name, price and calories are facts about the item; they stay the same across purchases, so they live in ITEM, stored once.
Quantity is a fact about one purchase; it changes every time, so it lives in BILL.
Restriction (i) is a uniqueness requirement on the bill, so make BillNo the primary key. Restriction (ii) is a referential requirement, so make ItemID a foreign key onto ITEM.
Choose data types by meaning: DECIMAL for money (exact fractions), INT for identifiers and quantity, VARCHAR for the name. Keeping calories in ITEM avoids redundancy and still answers "calories for this order" on demand.
Answer: Item facts (name, price, calories) in ITEM with ItemID PK; the event fact quantity in BILL with BillNo PK (unique bills) and ItemID FK to ITEM (bills only for existing items). Calories stay in ITEM.
Q 9
An organisation creates a database EMP-DEPENDENT: EMPLOYEE(AadharNumber, Name, Address, Department, EmployeeID) DEPENDENT(EmployeeID, DependentName, Relationship)
a) Name the attributes of EMPLOYEE that can be candidate keys. b) To retrieve a particular employee's dependents, name the tables and the key required. c) What is the degree of EMPLOYEE and DEPENDENT?
A candidate key is an attribute (or smallest set) whose value is unique for every tuple. To combine two tables you use the foreign key relationship, joining on the shared attribute. Degree is the number of attributes in a relation.
a) Candidate keys of EMPLOYEE.AadharNumber is unique for every person and EmployeeID is assigned uniquely by the company, so both are candidate keys. Name, Address and Department can repeat, so they are not.
b) Retrieving dependents. The details sit in DEPENDENT, but you start from a particular EMPLOYEE. The link is EmployeeID, which is the primary key in EMPLOYEE and the foreign key in DEPENDENT. So you need both tables joined on EmployeeID.
c) Degree. EMPLOYEE has 5 attributes (AadharNumber, Name, Address, Department, EmployeeID), so its degree is 5. DEPENDENT has 3 attributes (EmployeeID, DependentName, Relationship), so its degree is 3.
Answer: a) AadharNumber and EmployeeID. b) Tables EMPLOYEE and DEPENDENT, joined on EmployeeID. c) Degree of EMPLOYEE = 5, degree of DEPENDENT = 3.
NG
Neha Gupta
M.Tech Computer Science, IIT Kanpur
Verified Expert
Treat "candidate key" as the uniqueness test, "retrieve across tables" as the join key, and "degree" as a count.
Run the no-repeat test: Aadhar number and employee ID are unique by design, so both are candidate keys. Name fails (two people can share a name), address fails (a family shares one), department fails (many share it).
For (b), the bridge is the attribute common to both tables, EmployeeID, primary in EMPLOYEE and foreign in DEPENDENT. Name the direction explicitly.
For (c), degree is the column count: EMPLOYEE 5, DEPENDENT 3. The common slip is confusing degree with cardinality and counting rows.
A useful check: adding or removing rows never changes degree, which confirms you measured columns, not rows.
Answer: a) AadharNumber and EmployeeID. b) Join EMPLOYEE and DEPENDENT on EmployeeID. c) Degree EMPLOYEE = 5, DEPENDENT = 3.
Q 10
M/s Sheetal Pvt Ltd maintains a SCHOOL_UNIFORM database. Schema: UNIFORM(UCode PRIMARY KEY, UName NOT NULL, UColor) and COST(UCode, Size [composite PK], Price > 0). UNIFORM already has UCodes 1 to 6, and COST has rows for them.
a) Can these tuples be inserted into UNIFORM? Give reasons. i) 7, Handkerchief, NULL ii) 4, Ribbon, Red iii) 8, NULL, White b) Can these tuples be inserted into COST? Give reasons. i) 7, S, 0 ii) 9, XL, 100
Check each tuple against the constraints. In UNIFORM: UCode is the PRIMARY KEY (unique, not NULL), UName is NOT NULL, UColor is unconstrained. In COST: (UCode, Size) is a composite primary key, Price has a CHECK Price > 0, and UCode is a foreign key into UNIFORM.
a)(i) 7, Handkerchief, NULL. UCode 7 is new and unique, UName is not NULL, and UColor may be NULL. Allowed.
a)(ii) 4, Ribbon, Red. UCode 4 already exists (Tie), so this duplicates the primary key. Not allowed.
a)(iii) 8, NULL, White. UCode 8 is unique, but UName is NULL, which breaks the NOT NULL constraint. Not allowed.
b)(i) 7, S, 0. The pair (7, S) is fine, but Price = 0 fails the Price > 0 CHECK, and if UCode 7 is absent from UNIFORM the foreign key also fails. Not allowed.
b)(ii) 9, XL, 100. The composite key and Price 100 are fine, but UCode 9 does not exist in UNIFORM, so the foreign key fails. Not allowed.
Answer: a) (i) Allowed, (ii) Not allowed (duplicate UCode), (iii) Not allowed (UName NULL). b) (i) Not allowed (Price 0, and no parent), (ii) Not allowed (UCode 9 missing in UNIFORM).
IV
Ishaan Verma
M.Tech Computer Science, NIT Trichy
Verified Expert
Run every candidate row through a fixed checklist in the same order: primary key, then NOT NULL columns, then CHECK conditions, then foreign keys. A row is accepted only if it clears all of them.
Row a(i) clears all checks; the NULL colour is fine because UColor has no NOT NULL.
Row a(ii) fails the first check (duplicate UCode 4); a(iii) trips NOT NULL on UName.
Row b(i) fails the CHECK because Price 0 is not greater than zero; quote the missing parent too.
Row b(ii) is the trap: it looks clean, but the foreign key is checked last and rejects it because UCode 9 has no row in UNIFORM.
The lesson: passing some constraints is not enough; the foreign key quietly rejects rows that point at non-existent parents.
In a multiplex, one movie can be shown in more than one auditorium. Two relations are kept: Movie(Movie_ID, MovieName, ReleaseDate) Audi(AudiNo, Movie_ID, Seats, ScreenType, TicketPrice)
a) Is it correct to make Movie_ID the primary key of MOVIE? If not, suggest one. b) Is it correct to make AudiNo the primary key of AUDI? If not, suggest one. c) Is there any foreign key in either relation?
A primary key must be unique for every tuple. When one column alone cannot stay unique, a composite primary key (two or more columns) is used. A foreign key refers to the primary key of another table. The rule "one movie in many auditoriums" means Movie_ID repeats in AUDI.
a) Primary key of MOVIE. Each movie has a unique Movie_ID, so yes, it is correct to make Movie_ID the primary key.
b) Primary key of AUDI. One auditorium can show different movies and one movie can run in several auditoriums, so neither AudiNo nor Movie_ID alone stays unique. The pair (AudiNo, Movie_ID) uniquely identifies each screening, so use the composite primary key (AudiNo, Movie_ID), not AudiNo alone.
c) Foreign key.Movie_ID in AUDI refers to Movie_ID (the primary key of MOVIE), so it is a foreign key. MOVIE has none.
Answer: a) Yes, Movie_ID is valid for MOVIE. b) No, use the composite primary key (AudiNo, Movie_ID) in AUDI. c) Yes, Movie_ID in AUDI is a foreign key to MOVIE; MOVIE has none.
TJ
Tanvi Joshi
M.Tech Computer Science, IIT Roorkee
Verified Expert
Let the relationship sentence dictate the key: "one movie in many auditoriums" forces a composite key in AUDI.
Because Movie_ID must repeat across AUDI rows, it cannot be a sole primary key there, although it is fine in MOVIE where each movie appears once.
What pins down one AUDI row is the combination of auditorium and movie, so the natural primary key is the composite (AudiNo, Movie_ID).
For the foreign key, apply the definition: AUDI stores Movie_ID, the primary key of MOVIE, so it is the foreign key; MOVIE refers to nothing in AUDI.
Note that Movie_ID in AUDI plays two roles at once, part of the composite primary key and a foreign key, which is valid and common in many-to-many designs.
Answer: a) Yes for MOVIE. b) No, use composite primary key (AudiNo, Movie_ID) in AUDI. c) Movie_ID in AUDI is the foreign key onto MOVIE; MOVIE has none.
Q 12
For the Student Project Database, answer the questions below.
STUDENT
Roll No
Name
Class
Section
Registration_ID
11
Mohan
XI
1
IP-101-15
12
Sohan
XI
2
IP-104-15
21
John
XII
1
CS-103-14
22
Meena
XII
2
CS-101-14
23
Juhi
XII
2
CS-101-10
PROJECT_ASSIGNED
Registration_ID
ProjectNo
IP-101-15
101
IP-104-15
103
CS-103-14
102
CS-101-14
105
CS-101-10
104
(PROJECT has ProjectNo and PName.) a) Name the primary key of each table. b) Find the foreign key(s) in PROJECT_ASSIGNED. c) Is there any alternate key in STUDENT? Justify. d) Can a user assign a duplicate value to Roll No in STUDENT? Justify.
The primary key uniquely identifies rows; a candidate key not chosen as primary is an alternate key. A foreign key refers to the primary key of another table. A primary key must be unique, so duplicates are rejected (entity integrity).
a) Primary keys. STUDENT: Roll No. PROJECT: ProjectNo. PROJECT_ASSIGNED: Registration_ID (each registered student gets one project, so it is unique here).
b) Foreign keys in PROJECT_ASSIGNED.Registration_ID refers to STUDENT, and ProjectNo refers to PROJECT, so there are two foreign keys.
c) Alternate key in STUDENT. Both Roll No and Registration_ID are unique, so both are candidate keys. Roll No is chosen as primary, so Registration_ID becomes the alternate key.
d) Duplicate Roll No. No. Roll No is the primary key and must be unique under entity integrity, so the DBMS rejects any duplicate.
Answer: a) STUDENT to Roll No, PROJECT to ProjectNo, PROJECT_ASSIGNED to Registration_ID. b) Two foreign keys: Registration_ID and ProjectNo. c) Yes, Registration_ID is the alternate key. d) No, duplicates in the primary key Roll No are rejected.
AP
Arjun Pillai
M.Tech Computer Science, IIT Guwahati
Verified Expert
One observation drives most of this question: STUDENT has two unique columns.
Both Roll No and Registration_ID are unique, so both are candidate keys. Roll No is primary, making Registration_ID the alternate key (part c), and Roll No inherits the uniqueness guarantee so duplicates are rejected (part d).
In PROJECT_ASSIGNED each registration appears once, so Registration_ID is its primary key.
Apply the foreign-key definition to each column: Registration_ID matches STUDENT's primary key and ProjectNo matches PROJECT's, so both are foreign keys.
PROJECT_ASSIGNED is a junction table whose primary key is itself made of foreign-key columns, a pattern you will meet again in many-to-many designs.
Answer: a) Roll No / ProjectNo / Registration_ID. b) Two FKs in PROJECT_ASSIGNED. c) Registration_ID is the alternate key. d) No, the primary key Roll No rejects duplicates by entity integrity.
Q 13
For the same Student Project Database, can we perform the following? a) Insert a student record with a missing roll number. b) Insert a student record with a missing registration number. c) Insert a project detail without a submission date. d) Insert a record with Registration_ID IP-101-19 and ProjectNo 206 in PROJECT_ASSIGNED.
Use the same keys. In STUDENT, Roll No is the primary key and Registration_ID is an alternate (candidate) key, so both require unique, non-NULL values. Submission_Date in PROJECT is a plain attribute (NULL allowed unless NOT NULL is set). In PROJECT_ASSIGNED, both columns are foreign keys, so their values must already exist in the parent tables.
a) Missing roll number. Roll No is the primary key, and entity integrity forbids a NULL primary key, so this cannot be inserted.
b) Missing registration number. Registration_ID is a candidate / alternate key, which must be unique and not NULL, so this cannot be inserted.
c) Project without a submission date. Submission_Date is an ordinary attribute, so unless it carries NOT NULL a NULL is allowed, and this can be inserted.
d) Insert (IP-101-19, 206). Both columns are foreign keys. IP-101-19 is not in STUDENT and 206 is not in PROJECT, so both references fail referential integrity, and this cannot be inserted.
Answer: a) No (primary key cannot be NULL). b) No (alternate key must be unique and not NULL). c) Yes (non-key attribute, NULL allowed). d) No (both values are missing from the parent tables).
LR
Lakshmi Reddy
M.Tech Computer Science, IIIT Bangalore
Verified Expert
Classify each column first, then the answer is automatic.
Key columns (primary and candidate/alternate keys) must be unique and never NULL, so (a) and (b) are both refused. The common error in (b) is thinking only the primary key blocks NULL.
Plain attributes like the submission date carry no such rule, so (c) succeeds unless a NOT NULL is declared; state that assumption.
Foreign-key columns must reference an existing parent. In (d) both keys fail: IP-101-19 is absent from STUDENT and 206 is absent from PROJECT.
Entity integrity guards the keys and referential integrity guards the links, so any insert that weakens identity or breaks a link is refused before it is stored.
Answer: a) No (primary key Roll No cannot be NULL). b) No (alternate key Registration_ID must be unique and non-NULL). c) Yes (submission date is a plain attribute). d) No (both IP-101-19 and 206 are absent from the parent tables).
Ques. How many questions are there in NCERT Class 12 Computer Science Chapter 8 Database Concepts?
Ans. There are 13 end-of-chapter exercise questions in NCERT Class 12 Computer Science Chapter 8 Database Concepts. All 13 are solved with full answers and an Expert Solution. The mix is one "give the term" block, several differentiate and reasoning questions, one canteen database design question, and a set of key-spotting and insert-validity questions on given tables.
Ques. What is the difference between a candidate key, a primary key and an alternate key?
Ans. A candidate key is any minimal attribute set whose values are unique for every tuple, so it can identify a row on its own. A relation can have several candidate keys. One of them is chosen as the primary key, which must be unique and can never be NULL. Every candidate key that is not chosen as the primary key becomes an alternate key. For example, in a STUDENT table both Roll No and Registration_ID are candidate keys; if Roll No is chosen as primary, then Registration_ID is the alternate key.
Ques. Why is a foreign key allowed to have a NULL value?
Ans. A foreign key follows referential integrity, which says only that any value present in the foreign key column must already exist as a primary key in the parent table. NULL is the absence of a value, so the rule does not test it, which means a foreign key is allowed to be NULL. A NULL foreign key simply means "this row is not linked to any parent yet", such as an employee not yet assigned a department. The one exception is when the foreign key is also part of a primary key, because entity integrity then forbids NULL.
Ques. What is the difference between degree and cardinality of a relation?
Ans. Degree is the number of attributes (columns) in a relation, while cardinality is the number of tuples (rows). Degree is fixed by the table design and changes only when a column is added or dropped, whereas cardinality changes every time a row is inserted or deleted. A quick test is that an INSERT changes the cardinality but never the degree. For example, a table with 5 columns and 10 rows has degree 5 and cardinality 10.
Ques. How does a relational DBMS remove data redundancy compared to a file system?
Ans. A file system stores data in separate, application-owned files, so the same fact like a student's name and address is copied into many files. A relational DBMS stores all data once in a central shared database and uses normalisation to split data into related tables linked by keys. Other tables store only a small key, such as Roll_no, and refer back to the one place the full details live. Because each fact is stored only once, less storage is used and an update made once is seen everywhere, which also removes data inconsistency.
Ques. How many pages is the Class 12 Computer Science Database Concepts NCERT Solutions PDF?
Ans. The Database Concepts NCERT Solutions PDF runs about 22 pages and covers all 13 exercise questions with step-by-step reasoning, schema tables, labelled key diagrams, and an Expert Solution for each question. Both Normal and HD versions are available from this page, and both are free to download for the 2026-27 session.
Ques. Is the NCERT Solutions for Class 12 Computer Science Chapter 8 aligned with the 2026-27 syllabus?
Ans. Yes. This page reflects the current 2026-27 CBSE syllabus for Class 12 Computer Science. The Database Concepts chapter is unchanged for the current cycle, and every answer follows the NCERT textbook, covering the relational model, the key chain and the integrity constraints. The solutions are useful for the CBSE board exam, and the same database ideas help with CUET Computer Science and JEE-level computer-application questions.
Ques. What does a NULL value mean in a database?
Ans. A NULL is a special marker that means the value is unknown or not applicable. It is not the same as zero and not the same as a blank space or empty string. NULL is allowed in any non-key attribute, and it is also allowed in a stand-alone foreign key to mean "no related row yet". It is never allowed in a primary key, because entity integrity requires the primary key to identify every row, and a row with no identity cannot exist.
Comments