First time here? Checkout the FAQ!
+12 votes

Consider a relational table with a single record for each registered student with the following attributes:

  1. $\text {Registration_Num:}$ Unique registration number for each registered student
  2. $\text {UID:}$ Unique identity number, unique at the national level for each citizen
  3. $\text {BankAccount_Num:}$ Unique account number at the bank. A student can have multiple accounts or joint accounts. This attribute stores the primary account number.
  4. $\text {Name:}$ Name of the student
  5. $\text {Hostel_Room:}$ Room number of the hostel

Which of the following options is INCORRECT?

(A) $\text {BankAccount_Num}$ is a candidate key

(B) $\text {Registration_Num}$ can be a primary key

(C) $\text {UID}$ is a candidate key if all students are from the same country

(D) If $S$ is a super key such that $S \cap \text{UID}$ is $\text{NULL}$ then $S \cup \text{UID}$ is also a superkey

asked in Databases by Veteran (87.2k points)   | 781 views
plz ans this
here CKs are Registration_Num and UID

(D) If S is a super key, let (Name,Registration_Num), such that (Name,Registration_Num)∩UID is NULL then (Name,Registration_Num)∪UID is also a superkey​​​​​​​

3 Answers

+19 votes
Best answer

A relation is given (Registration_Num, UID, BankAccount_Num, Name, Hostel_Room).

Now, Registration_Num is unique for each student. So with this, we can identify each student. Hence, this can be the primary key.

UID: It's an identification number for a person in a country. (Say you're in India and your UID is 0243. Someone in Pakistan may also have the same UID as 0243). So, if all students are from India (that is, the same country) then their UID will be different and then UID will be a Candidate key.

If S is a super key then S $\cup$ UID will be a Super key. e.g.  R(A, B, C, D), If AB is a superkey then ABC, ABCD are also superkey.

BankAccount_Num is not a candidate key, because a student can have multiple accounts or joint accounts. We can not identify each student uniquely with BankAccount_Num.

answered by Boss (9.7k points)  
selected by
Is the reason given for BankAccount_Num correct? Even if we have multiple bank accounts for a single student but we are storing only the primary account number not all.

I understood that answer is A but please clear this doubt?
@Gaurab Ghosh

what happen when two students having joint bank account ??


Consider a relational table with a single record for each registered student

Thus two banks a/c for a single registered student is not allowed. That's why we cannot make bank a/c as a candidate key.

BankAccount_Num:BankAccount_Num: Unique account number at the bank

This clearly means that a student can have two same account numbers of different bank.But at bank level,account number of a student is unique. So, BankAccount_Num cannot be a Candidate Key.

+7 votes
Ans is A

can have possible duplicate values

As in case of joint account maybe 2 students  having joint account together.

In d) any non key attribute combined with superkey can uniquely identify all attributes.
answered by Boss (8k points)  
why not c?

UID: Unique identity number, unique at the "National level" for each citizen.
and in option C it is clearly mentioned that "if all students are from the same country" then UID is primary key..

ok tnks
–1 vote
Option B

As a student can have two bank accounts so for this particular student the relation will contain two tuples but for these two tuples registration_num is same so it can't be a primary key..
answered by Veteran (13.3k points)  
Der is single tuple bcoz Bank_Account_no stores information regarding primary bank account no only.

Related questions

Top Users Sep 2017
  1. Habibkhan

    6970 Points

  2. Warrior

    2490 Points

  3. Arjun

    2368 Points

  4. rishu_darkshadow

    2136 Points

  5. A_i_$_h

    2004 Points

  6. nikunj

    1980 Points

  7. makhdoom ghaya

    1760 Points

  8. manu00x

    1750 Points

  9. Bikram

    1744 Points

  10. SiddharthMahapatra

    1718 Points

26,060 questions
33,668 answers
31,079 users