CSS is the stylesheet language used to describe how HTML content should be displayed in a browser. It controls formatting elements like fonts, colors, spacing, and layout, applying styles to elements through selectors and resolving conflicts with its cascading rules. This matches the idea of formatting information on a webpage. By contrast, DDL is a database language for defining schemas, a Cursor is a database mechanism for iterating through query results, and a Database is the data storage system. So CSS is the correct choice because it directly handles how information appears on a webpage.

Normalization aims to reduce duplicate data and protect data integrity by organizing data into related tables and enforcing dependencies. When data is repeated across many rows, updating one piece of information in one place becomes risky: if a value changes, every instance must be updated correctly, or inconsistencies—update anomalies—occur. By splitting data into separate, logically connected tables (for example, one table for customers and another for orders) and linking them with keys, every fact is stored in one place, so updates, inserts, and deletes are done consistently. This structure minimizes storage waste and the chance of anomalies, prioritizing data accuracy and maintainability. It’s not primarily about speeding up queries, and normalization isn’t about storing binary data or enforcing access control.

In relational databases, a foreign key creates a link between two tables by referencing a key in another table. This is how relationships are modeled: a column (or set of columns) in one table points to the primary key (or another unique key) in a different table, establishing referential integrity. For example, an Orders table might have a CustomerID that references Customers.CustomerID. This ensures every order is associated with a valid customer, and you can join the tables to pull related data. A foreign key does not have to be unique within its table—many rows in the child table can reference the same parent row, enabling one-to-many relationships. It is different from a primary key, which uniquely identifies rows within its own table. And it’s not about permissions or storing large binary data; those correspond to other concepts.

Uniquely identifying each row in a table is the job of the primary key. It guarantees that no two rows share the same value for that key and, by default, it cannot be null, so every record has a distinct identity. This unique identifier is what other tables rely on when establishing relationships via foreign keys. A foreign key enforces referential integrity to another table but doesn’t by itself ensure that the rows in the local table are unique. An index improves search speed, but unless it’s defined as unique, it doesn’t guarantee uniqueness of rows. A private key is a cryptography concept and isn’t used to identify records in a database table. So the primary key best ensures that each record is unique.