GATE DA 2025 | Question: 46

Question

Consider the following two relations, named $\text{Customer}$ and $\text{Person},$ in a database:

Person (
aadhaar CHAR(12) PRIMARY KEY,
name VARCHAR(32));

Customer (
name VARCHAR (32),
email VARCHAR(32) PRIMARY KEY,
phone CHAR(10),
aadhaar CHAR(12),
   FOREIGN KEY (aadhaar) REFERENCES Person(aadhaar));

Which of the following statements is/are correct?

• A. $\text{aadhaar}$ is a candidate key in the $\text{Customer}$ relation
• B. $\text{phone}$ can be $\text{NULL}$ in the $\text{Customer}$ relation
• C. $\text{aadhaar}$ is a candidate key in the $\text{Person}$ relation
• D. $\text{aadhaar}$ can be $\text{NULL}$ in the $\text{Person}$ relation

Comments

A. False, because Aadhaar may be or may not be a candidate key, and it can have duplicates or NULL values.

B. True, because there is no NOT NULL Constraint on phone so it can be NULL.

C. True, because every primary key is a candidate key.

D. False, because aadhar is the Primary key in the Person relation, so it cannot be NULL. (Primary key= NOT NULL + UNIQUE)

Answer : $ B ,C$

Answer 1

Person Relation:
aadhaar is the Primary Key (hence unique and non-null).
name is a VARCHAR(32).

Customer Relation:

name is a VARCHAR(32).
email is the Primary Key.
phone is a CHAR(10).
aadhaar is a CHAR(12) and a Foreign Key referencing Person(aadhaar).

---

 

A. aadhaar is a candidate key in the Customer relation
False. A candidate key must be unique and capable of being a primary key. Since email is already the primary key in Customer, aadhaar may have duplicate or NULL values, it is not a candidate key.

B. phone can be NULL in the Customer relation
True. There is no constraint that phone must be NOT NULL, it can have NULL values.

C. aadhaar is a candidate key in the Person relation
True. Since aadhaar is the Primary Key in Person, it is a candidate key.

D. aadhaar can be NULL in the Person relation
False. Since aadhaar is a primary key in Person, it cannot be NULL.

Answer 2

Statement A: “aadhaar is a candidate key in the Customer relation.”

A candidate key is a minimal set of attributes that functionally determines all other attributes in a relation and is unique for every tuple.

In the Customer relation, the primary key is explicitly declared as $\texttt{email}$. No uniqueness constraint is imposed on $\texttt{aadhaar}$. As a foreign key, $\texttt{aadhaar}$ may appear multiple times (e.g., if a single person holds multiple customer accounts with different emails). Hence, $\texttt{aadhaar}$ is not guaranteed to be unique, and therefore cannot be a candidate key.

To illustrate, consider the following instance of Customer:

$$
\begin{array}{|c|c|c|c|}
\hline
\texttt{name} & \texttt{email} & \texttt{phone} & \texttt{aadhaar} \\
\hline
\text{Rahul} & \text{[email protected]} & 9876543210 & A123 \\
\text{Rahul} & \text{[email protected]} & 9876500000 & A123 \\
\hline
\end{array}
$$

Here, the same $\texttt{aadhaar = A123}$ appears in two distinct tuples, violating uniqueness. Thus, $\texttt{aadhaar}$ is not a candidate key in Customer.

---

Statement B: phone can be $\texttt{NULL}$ in the Customer relation.

In standard relational database systems, unless explicitly constrained with a $\texttt{NOT NULL}$ clause, a column allows $\texttt{NULL}$ values by default. The schema for Customer defines schema for phone but with no constraints of NULL

with no $\texttt{NOT NULL}$ clause. Therefore, $\texttt{phone}$ is nullable.

For example, a record with a missing phone number is valid:

$$
\begin{array}{|c|c|c|c|}
\hline
\texttt{name} & \texttt{email} & \texttt{phone} & \texttt{aadhaar} \\
\hline
\text{Priya} & \text{[email protected]} & \texttt{NULL} & B456 \\
\hline
\end{array}
$$

Statement B is true.

---

Statement C: “aadhaar is a candidate key in the Person relation.”

In the Person relation, $\texttt{aadhaar}$ is declared as the PRIMARY KEY. By definition, a primary key is a candidate key—specifically, the one chosen by the designer to uniquely identify tuples.

Since $\texttt{aadhaar}$ is a primary key, it is:

• Unique across all tuples,
• Non-null,
• Minimal (single attribute).

Hence, it qualifies as a candidate key.

Example instance of Person:

$$
\begin{array}{|c|c|}
\hline
\texttt{aadhaar} & \texttt{name} \\
\hline
A123 & \text{Rahul} \\
B456 & \text{Priya} \\
C789 & \text{Anjali} \\
\hline
\end{array}
$$

Each $\texttt{aadhaar}$ value is distinct and identifies a unique person.

Statement C is true.

---

Statement D: “aadhaar can be NULL in the Person relation.”

In SQL, primary key attributes cannot be NULL. This is a core integrity constraint: a primary key must uniquely and unambiguously identify each tuple, which is impossible if any component is missing.

Since $\texttt{aadhaar}$ is the primary key of Person, it must be non-null.

Thus, the following insertion would be rejected:

The correct statements are B and C.

Answer 3

Foreign key column:  

In theory (relational algebra), a foreign key cannot have NULL values since NULL is not part of the formal relational model.  

However, in SQL implementation, a foreign key can contain duplicate or NULL values, as long as any non-NULL value matches a valid primary key in the referenced table.  

Hence, aadhaar in the Customer table can be duplicate and NULL (in SQL).  Implies cannot be candidate key. 

 

phone column:  

There is no NOT NULL constraint specified, so phone can be NULL.  

 

aadhaar in Person:  

It is declared as a PRIMARY KEY, which implies it is unique and cannot be NULL.  

 

Candidate key in Customer:  

Since aadhaar can be NULL and duplicate, it cannot be a candidate key.  

The primary key of Customer is email, which is the only candidate key here.

Answer 4

Good Luck Everyone