FC0-U71 Data and Database Fundamentals Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  A foreign key value must match an existing primary key value in the referenced table, or be NULL if the column allows it.

  Why this is correct

  This is accurate because referential integrity requires every non-null foreign key value to correspond to an existing referenced key. The exception is when the foreign key column permits NULL, which represents the absence of a relationship, such as an unassigned order. This rule prevents orphaned rows that point to nonexistent parent records.

• ✓

  A primary key uniquely identifies each row in its table and cannot contain NULL values.

  Why this is correct

  This is accurate because a primary key enforces uniqueness across all rows and, by definition, rejects NULLs so every row has a known identifier. Databases implement this with a unique constraint plus a not-null requirement. This guarantee is what allows other tables to reference a specific row reliably, making it a foundational rule of relational design.

• ✗

  A primary key value can be changed freely at any time without affecting related tables.

  Why it's wrong here

  Changing a primary key value can break or cascade to every foreign key that references it, depending on whether ON UPDATE CASCADE or ON UPDATE RESTRICT is defined. Most designs treat primary keys as stable and rarely modified. Claiming it can change freely ignores referential integrity, so this statement is false.

• ✗

  A foreign key must be unique within its own table.

  Why it's wrong here

  Foreign keys are commonly duplicated, which is how one-to-many relationships work: many child rows can reference the same parent key. Requiring uniqueness would force a one-to-one relationship and break normal designs such as many orders sharing one customer. Uniqueness is a property of primary keys and unique constraints, not foreign keys.

• ✗

  A table can contain multiple primary keys to improve query performance.

  Why it's wrong here

  A table may have only one primary key, though that key can span multiple columns as a composite key. Adding a second primary key is not permitted because it would create two competing unique identifiers for the same row. Performance improvements come from indexes or unique constraints, not from declaring extra primary keys.