Purpose of Normalization
Why is database normalization important in the design of relational schemas?
- It helps eliminate redundant data and inconsistent dependencies.
- It increases the number of joins required for all queries.
- It allows storing unrelated data in the same table.
- It guarantees the fastest performance in all cases.
- It makes it easier to store multiple values in a single column.
First Normal Form (1NF)
Which of the following tables violates first normal form?
- A table with a single column storing an array of phone numbers per row.
- A table where each row stores a single value for each attribute.
- A table with a numeric primary key.
- A table that contains unique row identifiers.
- A table that has columns such as first_name and last_name.
Second Normal Form (2NF)
Suppose you have a table with a composite primary key (OrderID, ProductID) and a column ProductName. What is the normalization issue?
- ProductName should depend only on ProductID, not on both OrderID and ProductID.
- ProductName should depend only on OrderID.
- ProductName should be split into firstName and lastName.
- ProductName can depend on any key in the table.
- ProductName should not be included in the table.
Third Normal Form (3NF)
A student table includes StudentID, Name, Advisor, and AdvisorRoom columns. What causes it to fail third normal form?
- AdvisorRoom is dependent on Advisor, not StudentID.
- StudentID is not unique.
- AdvisorRoom is a numeric field.
- There is no primary key.
- Name should be split into first and last names.
Naming Conventions Best Practice
Which of the following is the best practice for naming columns in a relational database?
- Use clear, descriptive names like CustomerAddress.
- Use abbreviated names such as CAddrss.
- Include spaces in the name, like 'Customer Address'.
- Add metadata prefixes, such as tblCustomer.
- Mix camelCase and snake_case within the same schema.
Surrogate vs Natural Keys
What is an important guideline when using surrogate keys in database design?
- Ensure there is also a unique natural key to enforce real-world uniqueness.
- Rely only on surrogate keys and ignore natural uniqueness.
- Use only string-based surrogate keys.
- Never use surrogate keys in any table.
- Surrogate keys should be user-facing IDs.
Domain Tables
What is a common problem with using a single 'catch-all' domain table for different kinds of lookup values?
- It mixes unrelated data, making joins and queries unnatural.
- It improves query performance significantly.
- It enforces foreign key integrity perfectly.
- It prevents the need for documentation.
- It is always preferred for normalization.
Documenting Schemas
Why should you document tables and columns in your database schema?
- So other developers and future maintainers can easily understand the data model.
- To make the table names longer.
- To avoid using any constraints.
- So that the schema can be exported as plain text only.
- To store business rules only in application code.
Constraints and Business Rules
Which business rules should ideally be enforced at the database level?
- Fundamental, non-changing rules such as nullability and valid value ranges.
- Temporarily changing rules like maximum monthly discounts.
- Visual formatting rules.
- Presentation-layer requirements.
- All validation should be done only in the application layer.
Performance and Normalization
Which statement best reflects practical advice regarding normalization and performance?
- Normalize until it hurts, then denormalize until it works.
- Always fully normalize, no matter the cost.
- Never normalize if you can avoid it.
- The more tables, the slower your database will be, without exception.
- Denormalize by default, as normalization is always slow.