به انگلیسی

Keys that decide everything

Computing · Data & Databases · ages 18-19

Name ______________________ Date ____________

Which condition defines a candidate key under the given functional dependencies?
- Its closure reaches all attributes, even if starting attributes can be removed
- Its closure reaches all attributes, but no proper subset's closure does
- It has fewer attributes than every other set that identifies tuples in the relation
The rule student ID -> email holds in every allowed state. What does it require?
- Tuples with the same ID have the same email
- Tuples with the same email must always have the same student ID
- Every student ID must use the one email shared by all other students
A relation is in BCNF exactly when every nontrivial functional dependency has a superkey on its left.
Circle one: True False
R(A,B,C) has only the given rules A -> B and B -> A, plus their consequences. Which list contains all candidate keys?
- {A,C} and {B,C}
- {A} and {B}, since C can be left out
- {A,B,C} only, since every starting attribute is required
R has attributes A, B and C. Using the rules A -> B and B -> C, what is {A}+?
- {A,B}
- {A}
- {A,B,C}
R has A, B, C and D. Its only given rules are A,B -> C and C -> D. How many attributes are in {A}+?
Answer: ______________
R(ID,email,dorm) has only ID -> email and email -> dorm, plus their consequences. Which split on email -> dorm retains every attribute and is lossless?
- R1(ID) and R2(email,dorm), with no shared linking attribute
- R1(ID,email) only, removing dorm to remove the dependency
- R1(ID,email) and R2(email,dorm)
R(ID,email,dorm) has only ID -> email and email -> dorm, plus their consequences. Pat says it is in BCNF because email is unique today. Why does that not establish BCNF?
- BCNF requires numeric identifiers and cannot use an email attribute as a determinant
- email+ lacks ID, so email is not a superkey under the rules
- Every determinant must contain exactly one attribute, so a different schema is needed

Answer key

For grown-ups. Fold this page away before handing over the rest.

Keys that decide everything W1-mt_PfWLq1aEQz-s1

Its closure reaches all attributes, but no proper subset's closure does · A candidate key is a minimal superkey. No starting attribute can be removed while retaining a superkey.
Tuples with the same ID have the same email · Agreement on the left forces agreement on the right. The dependency does not require the reverse direction.
True · This is the BCNF condition. A superkey may contain extra attributes, and trivial dependencies are exempt.
{A,C} and {B,C} · No rule adds C, so every key needs it. Adding A or B determines the other. Both resulting sets are minimal superkeys.
{A,B,C} · Start with A, add B through A -> B, then add C through B -> C.
1 · A,B -> C needs both A and B. Starting with A alone adds nothing, so the closure contains one attribute.
R1(ID,email) and R2(email,dorm) · Shared email determines the email/dorm piece. Joining the two projections on email reconstructs exactly the original relation.
email+ lacks ID, so email is not a superkey under the rules · email -> dorm is nontrivial, but email+ is {email,dorm}. Today's uniqueness does not establish a rule determining ID.