BCNF – Boyce–Codd Normal Form — Learn free

Self-check

Questions 1–10 of 10

1. How is Boyce–Codd Normal Form (BCNF) related to Third Normal Form?
Question 1A. It is a stricter refinement of 3NFB. It is a looser version of 3NF for analytical systemsC. It is an alternative name for 3NFD. It is the form that precedes 3NFE. It replaces 3NF with multi-valued dependency rules
2. What is the formal condition for a table to be in Boyce–Codd Normal Form?
Question 2A. Every attribute holds an atomic valueB. For every functional dependency X → Y, the determinant X is a superkey of the relationC. No non-key attribute depends on part of a composite keyD. Every table has exactly one candidate keyE. All multi-valued dependencies have been decomposed
3. In the loan approval BCNF example with LoanID, ProductType and InterestRate, which functional dependency causes the problem?
Question 3A. LoanID → ProductTypeB. InterestRate → LoanIDC. ProductType → InterestRateD. LoanID → InterestRateE. InterestRate → ProductType
4. Why does the table with LoanID as primary key and the dependency ProductType → InterestRate violate Boyce–Codd Normal Form?
Question 4A. Because InterestRate is a multi-valued attributeB. Because LoanID is a composite keyC. Because ProductType depends on only part of the keyD. Because ProductType is not a superkey; multiple loans may share the same product typeE. Because InterestRate is stored as text
5. What anomaly arises when InterestRate is stored in the Loan table alongside ProductType?
Question 5A. Loan rows can no longer be uniquely identifiedB. The interest rate becomes non-atomicC. The product type must be duplicated as a keyD. Repayments cannot be linked to loansE. The same interest rate repeats across many loan rows and a rate change requires multiple updates
6. How is the LoanID, ProductType, InterestRate table decomposed to satisfy Boyce–Codd Normal Form?
Question 6A. ProductType and InterestRate move to a separate table keyed by ProductType, and the Loan table references ProductType through a foreign keyB. InterestRate is moved into the Repayment tableC. LoanID and ProductType are combined into a composite keyD. InterestRate is dropped and recalculated at query timeE. The table is left unchanged but an index is added on ProductType
7. What is the key difference between Third Normal Form and Boyce–Codd Normal Form?
Question 7A. 3NF removes repeating groups whereas BCNF removes partial dependenciesB. 3NF allows a non-superkey to determine an attribute that is part of a candidate key; BCNF removes that allowance entirelyC. 3NF applies to transactional systems whereas BCNF applies only to warehousesD. 3NF requires atomic values whereas BCNF does notE. 3NF handles join dependencies whereas BCNF handles multi-valued dependencies
8. In practice, how do most well-designed 3NF schemas relate to Boyce–Codd Normal Form?
Question 8A. They usually violate BCNF and need major redesignB. They must be denormalised before reaching BCNFC. They already satisfy BCNFD. They cannot be evaluated against BCNFE. They satisfy BCNF only if they use surrogate keys
9. Which of the following is NOT a claim made about Boyce–Codd Normal Form?
Question 9A. It is the final stage of normalisation commonly required for transactional systemsB. It ensures stronger structural integrity in schemas with overlapping dependenciesC. It requires every determinant to be a superkeyD. It addresses multi-valued and join dependenciesE. It makes the relational structure mathematically disciplined
10. What do the normal forms beyond Boyce–Codd Normal Form address?
Question 10A. Atomic values and repeating groupsB. Partial dependencies on composite keysC. Transitive dependencies through non-key attributesD. Foreign key naming conventionsE. Multi-valued and join dependencies rather than basic redundancy