正在加载图片...
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 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 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 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] 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 con￾straints. The domain constraints for Special acct schema require that, for each ac￾count, • The account number begins with 9. • The balance is greater than 2500
<<向上翻页向下翻页>>
©2008-现在 cucdc.com 高等教育资讯网 版权所有