B.3 Domain-Key Normal Form 9 B.3 Domain-Key Normal Form The approach we have taken to normalization is to define a form of constraint (functional,multivalued,or join dependency),and then to use that form of con- straint to define a normal form.Domain-key normal form(DKNF)is based on three notions 1.Domain declaration.Let A be an attribute,and let dom be a set of values. The domain declaration A dom requires that the A value of all tuples be values in dom. 2.Key declaration.Let R be a relation schema with KR.The key declaration key(K)requires that K be a superkey for schema R-that is,K-R.Note that all key declarations are functional dependencies but not all functional dependencies are key declarations. 3.General constraint.A general constraint is a predicate on the set of all re- lations on a given schema.The dependencies that we have studied in this chapter are examples of general constraints.In general,a general constraint is a predicate expressed in some agreed-on form,such as first-order logic. We now give an example of a general constraint that is not a functional, multivalued,or join dependency.Suppose that all accounts whose account number begins with the digit 9 are special high-interest accounts with a minimum balance of $2500.Then,we include as a general constraint,"If the first digit of t[account number]is9,then t[balance]≥2500.” Domain declarations and key declarations are easy to test in a practical database system.General constraints,however,may be extremely costly(in time and space)to test.The purpose of a DKNF database design is to allow us to test the general constraints using only domain and key constraints. Formally,let D be a set of domain constraints and let K be a set of key constraints for a relation schema R.Let G denote the general constraints for R. Schema R is in DKNF if D UK logically implies G. Let us return to the general constraint that we gave on accounts.The constraint implies that our database design is not in DKNF.To create a DKNF design,we need two schemas in place of Account_schema: Regular acct schema (account number,branch name,balance) Special acct schema =(account number,branch name,balance) We retain all the dependencies that we had on Account schema as general con- straints.The domain constraints for Specialacct-schema require that,for each ac- count, The account number begins with 9. The balance is greater than 2500.B.3 Domain-Key Normal Form 9 B.3 Domain-Key Normal Form The approach we have taken to normalization is to define a form of constraint (functional, multivalued, or join dependency), and then to use that form of constraint to define a normal form. Domain-key normal form (DKNF) is based on three notions. 1. Domain declaration. Let A be an attribute, and let dom be a set of values. The domain declaration A ⊆ dom requires that the A value of all tuples be values in dom. 2. Key declaration. Let R be a relation schema with K ⊆ R. The key declaration key (K) requires that K be a superkey for schema R—that is, K → R. Note that all key declarations are functional dependencies but not all functional dependencies are key declarations. 3. General constraint. A general constraint is a predicate on the set of all relations on a given schema. The dependencies that we have studied in this chapter are examples of general constraints. In general, a general constraint is a predicate expressed in some agreed-on form, such as first-order logic. We now give an example of a general constraint that is not a functional, multivalued, or join dependency. Suppose that all accounts whose account number begins with the digit 9 are special high-interest accounts with a minimum balance of $2500. Then, we include as a general constraint, “If the first digit of t[account number] is 9, then t[balance] ≥ 2500.” Domain declarations and key declarations are easy to test in a practical database system. General constraints, however, may be extremely costly (in time and space) to test. The purpose of a DKNF database design is to allow us to test the general constraints using only domain and key constraints. Formally, let D be a set of domain constraints and let K be a set of key constraints for a relation schema R. Let G denote the general constraints for R. Schema R is in DKNF if D ∪ K logically implies G. Let us return to the general constraint that we gave on accounts. The constraint implies that our database design is not in DKNF. To create a DKNF design, we need two schemas in place of Account schema: Regular acct schema = (account number, branch name, balance) Special acct schema = (account number, branch name, balance) We retain all the dependencies that we had on Account schema as general constraints. The domain constraints for Special acct schema require that, for each account, • The account number begins with 9. • The balance is greater than 2500