A table employee_skills(employee_id, skill, language) records that an employee has a skill AND speaks a language — but the two facts are actually completely independent of each other (an employees skills dont depend on which languages they speak, or vice versa). What normal form violation does storing both independent multi-valued facts in one table create, and what does 4NF require?
AThis is a 3NF violation, since skill and language are both non-key attributes
BThis is fine as-is; 4NF only applies to numeric columns
CThis is a multi-valued dependency problem: cramming two independent one-to-many facts about the same entity into one table forces redundant combinations (every skill paired with every language) just to represent both facts. 4NF requires splitting them into two separate tables — employee_skills(employee_id, skill) and employee_languages(employee_id, language) — each capturing one independent multi-valued fact
D4NF requires merging skill and language into a single combined column
A products table has 12 commonly-queried columns and 30 rarely-used, bulky columns (long descriptions, spec sheets) that most queries never touch. Whats a common design response to this, and whats the trade-off?
ANothing should be done; PostgreSQL automatically optimizes column access regardless of table width
BRarely-used columns should always be deleted rather than stored
CPostgreSQL requires every table to have exactly one 1:1 companion table by default
DSplitting the rarely-used columns into a separate product_details table with a 1:1 relationship (product_details.product_id as both its primary key and a foreign key to products.id) keeps the "hot" products table narrower and faster to scan for common queries, at the cost of needing a JOIN whenever the detail columns actually are needed
Which constraint correctly ensures every bookings row has a valid time range, where the row's own start_date must come before its own end_date?
AFOREIGN KEY (start_date) REFERENCES bookings (end_date)
BUNIQUE (start_date, end_date)
CCHECK (start_date < end_date)
DThis can't be enforced at the database level; it must be validated in application code only