Q.Observe the following tables, EMPLOYEES and DEPARTMENT carefully and answer the questions that follow: TABLE : EMPLOYEES ENO ENAME DOJ DNO E1 NUSRAT 2001-11-21 D3 E2 KABIR 2005-10-25 D1 TABLE : DEPARTMENT DNO DNAME D1 ACCOUNTS D2 HR D3 ADMIN
🔒You're viewing a preview — the full solution, concept, methods & PYQ mapping are locked.
🔒 Start your 14-day free trial to unlock the full solution →Part (a)Concept understanding — Database Fundamentals
Database Fundamentals
Think of a database as a well-organised filing cabinet. In your daily life, you already manage small databases without realising it — your phone's contact list, the catalogue of a library, or even the list of students in a class register. Each of these is a collection of related information stored in a structured way so that you can find what you need quickly.
What Exactly Is a Database?
A database is a collection of related data that is stored and managed systematically. The key word here is related. A random pile of papers on a desk is not a database — but the same papers, sorted into folders with labels and a clear order, become one. The purpose of a database is to allow efficient storage, retrieval, modification, and deletion of data.
A database is not the same as a spreadsheet. A spreadsheet is a single table meant for one person's use. A database is designed for multiple users, handles large volumes of data, and ensures that the data remains consistent even when many people access it at once.
Why Do We Need Databases?
Imagine a small business that keeps customer orders in a notebook. As the business grows, the notebook becomes impossible to manage — pages get lost, two customers might be given the same order number, and finding a specific order takes forever. A database solves all these problems.
Databases provide:
- Centralised control — all data lives in one place, so everyone works with the same information
- Data consistency — rules can be enforced (for example, an order must belong to a real customer)
- Security — different users can be given different levels of access
- Reduced redundancy — the same piece of information is not stored in multiple places unnecessarily
- Data independence — the way data is stored can change without affecting how users view it
The Core Idea: Tables and Relationships
The most common type of database is the relational database. Think of it as a collection of tables, where each table stores information about one kind of thing.
A table is made up of rows and columns. Each column represents a field (a single piece of information, like a name or a date), and each row represents a record (one complete set of fields, like one customer's full details).
For example, a university might have a Student table with columns: Roll Number, Name, Date of Birth, and Course. Each row is one student.
The real power comes from relationships between tables. The same university might have a Course table and an Enrolment table. The Enrolment table links a student to a course using the student's roll number and the course code — without repeating all the student's details or all the course details. This is what makes a database efficient.
The primary key is a column (or a set of columns) that uniquely identifies each row in a table. For the Student table, Roll Number is the primary key — no two students can share the same roll number. A foreign key is a column in one table that refers to the primary key of another table, creating the link between them.
Database Management System (DBMS)
A Database Management System is the software that lets you create, manage, and interact with a database. You do not directly touch the data files — the DBMS does that for you. Popular examples include MySQL, Oracle, and Microsoft Access.
The DBMS handles:
- Data storage and retrieval — it decides how to physically store data on a disk
- Query processing — when you ask for "all students born after 2005", the DBMS finds the answer …
Part (b)Concept understanding — Relational Algebra Operations
Relational Algebra Operations: A First Look
Think of a relational database as a collection of neat, rectangular tables. Each table has rows (records) and columns (attributes). Now, suppose you want to ask questions of this data — "Which customers live in Delhi?" or "Show me all orders placed last month." Relational algebra is the set of basic operations you use to answer such questions. It is the language of queries at the most fundamental level.
You do not need to write code or do math. You only need to understand what each operation does to a table — like a set of tools in a toolbox.
The Core Operations
There are eight classic operations. They fall into two groups: those that work on one table at a time, and those that combine two tables.
Operations on a Single Table
Select (also called Restrict) — This operation picks certain rows from a table based on a condition. For example, from a table of students, you might select only those rows where the city is "Mumbai". The result is a smaller table with the same columns but fewer rows.
Project — This operation picks certain columns from a table. For example, from a student table with columns Roll No, Name, City, and Marks, you might project only Name and City. The result is a table with fewer columns. Duplicate rows are automatically removed.
Rename — This operation simply gives a new name to the resulting table or to its columns. It is useful when you need to refer to the same table more than once in a query, or when you want clearer column headings.
Select and Project are the two most frequently used operations. Select narrows down rows; Project narrows down columns. Together they let you extract exactly the slice of data you need.
Operations That Combine Two Tables
Union — This combines two tables that have the same structure (same number of columns and compatible data types). The result contains all rows that appear in either table, with duplicates removed. Think of it as "add the rows of one table to the rows of another, but keep only unique ones."
Set Difference — This gives you rows that are in the first table but not in the second. For example, "Which students are enrolled in Course A but not in Course B?"
Intersection — This gives you rows that appear in both tables. For example, "Which customers have bought both a laptop and a printer?"
Cartesian Product — This pairs every row of the first table with every row of the second table. If the first table has 10 rows and the second has 5, the result has 50 rows. This operation is rarely used alone — it is the foundation for the most powerful operation of all.
Join — This is the heart of relational algebra. A join combines rows from two tables based on a related column between them. For example, you have a Customers table and an Orders table. The join operation matches each order to the customer who placed it, using the Customer ID column that appears in both tables. The result is a single table with all the customer details alongside their orders.
The Join operation is what makes relational databases relational. Without it, data in separate tables would remain isolated. Joins let you connect information across tables — customers to orders, students to courses, products to suppliers — and answer questions that span multiple pieces of data.
Why Relational Algebra Matters …
Part (a)
(i) Degree = number of columns; EMPLOYEES has ENO, ENAME, DOJ, DNO -> degree = 4. Cardinality = number of rows; DEPARTMENT has D1, D2, D3 -> cardinality = 3.
(ii) A Primary Key is a column (or set of columns) that uniquely identifies each row of a table. It must have unique values and cannot be NULL. For EMPLOYEES, ENO is the primary key because each employee has a distinct ENO. …
Part (a): degree of EMPLOYEES = 4, cardinality of DEPARTMENT = 3; a primary key uniquely identifies each row. Part (b): Selection chooses rows by condition (horizontal), Projection chooses columns (vertical).
Part (a)
(i) In relational-database terms, the degree of a table is its number of columns (attributes). EMPLOYEES has four columns — ENO, ENAME, DOJ, DNO — so its degree is 4. The cardinality is the number of rows (tuples). DEPARTMENT has three rows (D1, D2, D3), so its cardinality is 3. …
- CBSE 2026Set 91/41 markMCQQ.A relation in MySQL database consists of 2 tuples and 3 attributes. If 2 attributes are deleted and 4 tuples are added, what will be the cardinality of the relation ? (A) 4 (B) 5 (C) 6 (D) 7
›Reveal solutionSolution
Cardinality refers to the number of tuples (rows) in a relation; deleting attributes affects only the structure, not the row count, so starting with 2 tuples and adding 4 more gives a cardinality of 6.
Understanding what happens to a relation when we modify its structure or content requires clarity on two fundamental terms: cardinality and degree. Cardinality is the number of tuples (rows) in a relation—essentially, how many records the table holds. Degree, on the other hand, is the number of attributes (columns)—the structure of the relation itself.
The question begins with a relation containing 2 tuples and 3 attributes. Picture a small table with three columns and two rows of data. Now, two operations are performed: first, 2 attributes are deleted, and second, 4 tuples are added.
Deleting attributes changes the degree of the relation. If we remove 2 out of 3 attributes, we are left with a single-column table. This operation affects the structure—the width of the table—but it does not touch the number of rows. The 2 tuples that were already present remain in the relation; they simply have fewer fields now. …
- CBSE 2025Set 91/41 markQ.State True or False : If table A has 6 rows and 3 columns, and table B has 5 rows and 2 columns, the Cartesian product of A and B will have 30 rows and 5 columns.
›Reveal solutionSolution
The statement is True — the Cartesian product of two tables combines every row of one with every row of the other, so the number of rows multiplies and the number of columns adds.
Let's think about what the Cartesian product actually does. In relational algebra, when you take the Cartesian product of two tables (say A and B), you are pairing each row of A with every row of B. The result is a new table that contains all possible combinations of rows from the two original tables.
The number of rows in the product is the product of the row counts of A and B. Here, A has 6 rows and B has 5 rows, so the result has 6 x 5 = 30 rows.
What about the columns? The Cartesian product does not merge or eliminate any columns — it simply places all columns from A side by side with all columns from B. So the total number of columns is the sum of the column counts of A and B. A has 3 columns, B has 2 columns, so the result has 3 + 2 = 5 columns.
NoteThis is exactly how the Cartesian product works in relational algebra — it is a cross join, not a natural join. No matching or merging of columns happens; every column from both tables appears in the output. …
- CBSE 2023Set 91/11 markMCQQ.Fill in the blank. ............. is a number of tuples in a relation.(a) Attribute(b) Degree(c) Domain(d) Cardinality
›Reveal solutionSolution
Cardinality is the term used for the number of tuples (rows) in a relation — it tells you how many records the table holds.
In database terminology, a relation is essentially a table. Each row in that table is called a tuple, and each column is called an attribute. When we talk about how many rows a relation contains, we are referring to its cardinality.
Think of a classroom register. If the register has 40 students listed, the cardinality of that register (as a relation) is 40. It is a count of the records present. This is a fundamental concept because it tells you the size of the data set you are working with — a high cardinality means many records, a low one means few.
The other options in the question are distinct concepts. An attribute is a column heading (like "Student Name" or "Roll Number"). The degree of a relation is the number of attributes (columns) it has, not the rows. A domain is the set of permissible values for a given attribute — for example, the domain for "Age" might be all positive integers up to 120. …
- CBSE 2023Set 91/41 markMCQQ.Fill in the blank : In a relational model, tables are called _________, that store data for different columns.(a) Attributes(b) Degrees(c) Relations(d) Tuples
›Reveal solutionSolution
In the relational model, tables are formally called relations — the foundational structure that organizes data into rows and columns.
The relational model, introduced by E.F. Codd in 1970, revolutionized how we think about organizing and managing data. At its heart lies a beautifully simple mathematical concept borrowed from set theory: the relation. When we work with databases today, we casually call them "tables," but the formal term that captures their essence is relation.
A relation is not just any collection of data. It is a structured entity with a specific schema — a set of attributes (the columns) and a collection of tuples (the rows) that conform to that schema. Think of it as a contract: every relation promises that its data will fit a particular shape, with each column representing a specific attribute and each row representing one complete record or tuple.
The terminology here is precise and worth understanding:
- Attributes are the columns themselves — the individual properties or fields like "Student_ID," "Name," or "Marks." They define what kind of information each column holds.
- Tuples are the rows — the actual data entries, each representing one complete instance (one student, one product, one transaction).
- Degree refers to the number of attributes (columns) in a relation.
- Relations are the tables as a whole — the complete structure that binds attributes and tuples together under a single name. …
🎓Unlock everything free for 14 days
- ✓Full step-by-step solutions
- ✓Concept-first explanations
- ✓Methods, shortcuts & mistakes
- ✓PYQ mapping + timed mock tests
Full access for 14 days. No credit card required.