A database table currently has the property that every row with ZipCode = '90210' also has City = 'Beverly Hills.' What can you conclude about the functional dependency ZipCode → City?
AZipCode → City holds — the data proves it
BZipCode → City may or may not hold — the current data is consistent with it, but an FD must hold for all possible future data
CZipCode → City definitely holds, because zip codes and cities have a one-to-one relationship
DZipCode → City holds only if ZipCode is the primary key
An FD is a constraint on all possible valid data, not an observation about current data. Today's table may happen to be consistent with ZipCode → City, but this proves nothing — someone could insert a new zip code with a different city, violating the constraint if it were declared. The FD is a design decision: you are declaring that your schema requires this relationship to always hold. Observing it in current data is necessary but not sufficient evidence that the FD is intended as a constraint.
Question 2 Multiple Choice
In a student table, the FD StudentID → Name holds. A data-entry error creates two rows with the same StudentID but different Names. What is true?
AThe FD no longer holds — functional dependencies can change as data changes
BThe FD is violated — the data is inconsistent with the declared constraint
CThe FD still holds for all other rows, so the table is partially valid
DThis situation is impossible if StudentID is a primary key, so no FD is violated
If StudentID → Name is declared as an FD, then any two rows agreeing on StudentID must agree on Name — without exception. Two rows with the same StudentID and different Names violate this constraint. The FD is a declarative assertion about all valid states of the database; a violation means the data is in an invalid state. This is exactly the kind of anomaly that normalization prevents: the FD makes explicit what the data model requires, so violations can be detected and prevented.
Question 3 True / False
A functional dependency X → Y means that knowing X causes Y to take a particular value in some physical or logical sense.
TTrue
FFalse
Answer: False
False. An FD is a data constraint, not a causal relationship. X → Y means only that in any valid instance of the relation, two tuples agreeing on X must agree on Y. It says nothing about why — there is no causal mechanism implied. ZipCode → City holds in a postal database not because zip codes physically cause cities to exist, but because the data model declares that the postal system assigns each zip code to exactly one city. Confusing constraint with causation leads to errors in schema design.
Question 4 True / False
A candidate key is a minimal superkey: it determines all attributes of the relation, and no proper subset of it also determines all attributes.
TTrue
FFalse
Answer: True
True. A superkey K satisfies K → (all attributes). A candidate key is a superkey with no redundant attributes — remove any single attribute from it and it no longer determines everything. In practice, computing candidate keys requires finding the closure K⁺ under the given FDs: if K⁺ equals all attributes, K is a superkey; if no proper subset of K has this property, K is a candidate key. Primary keys are chosen from among the candidate keys.
Question 5 Short Answer
Why does the distinction between 'an FD appearing to hold in current data' versus 'an FD declared as a design constraint' matter for database design?
Think about your answer, then reveal below.
Model answer: Because normalization decisions are based on FDs as constraints, not as observations. If you declare ZipCode → City and store City in a table keyed by something else, you create redundancy — every row with that zip code repeats the city name. This causes update anomalies (changing the city requires updating many rows) and insertion anomalies (you can't record a new zip/city pair without a full row). If the FD only appears to hold currently, normalizing based on it may split the table incorrectly when future data violates the assumed dependency.
The practical consequence: before declaring an FD, you must verify it reflects a real-world constraint — not just a coincidence in today's data. An FD like EmployeeID → Department might appear in data today but might not be a true constraint (an employee could be reassigned). Treating a coincidence as an FD and normalizing around it produces a schema that cannot represent future valid states of the world. FDs must be grounded in domain knowledge, not data mining.