Database Modeling & Design Fourth Edition- P31 docx

6.6 Summary 137 A many-to-many-to-many ternary relationship is: • BCNF if it can be replaced by two binary relationships • 4NF if it can only be replaced by three binary relationships • 5NF if it cannot be replaced in any way (and thus is a true ternary relationship) We observe the equivalence between certain ternary relationships and the higher normal form tables transformed from those relation- ships. Ternary relationships that have at least one “one” entity cannot be decomposed (or broken down) into binary relationships, because that would destroy the one or more FDs required in the definition, as shown previously. A ternary relationship with all “many” entities, however, has no FDs, but in some cases may have MVDs, and thus have a lossless decomposition into equivalent binary relationships. In summary, the three common cases that illustrate the correspon- dence between a lossless decomposition in a many-to-many-to-many ternary relationship table and higher normal forms in the relational model are shown in Table 6.8. 6.6 Summary In this chapter, we defined the constraints imposed on tables—most commonly the functional dependencies or FDs. Based on these con- straints, practical normal forms for database tables are defined: 1NF, 2NF, 3NF, and BCNF. All are based on the types of FDs present. In this chapter, a practical algorithm for finding the minimum set of 3NF tables is given. Table 6.8 Summary of Higher Normal Forms Table Name Normal Form Two-way Lossless decomp/join? Three-way Lossless decomp/join? Nontrivial MVDs skill_required BCNF yes yes 2 skill_in_ common 4NF no yes 0 skill_used 5NF no no 0 Teorey.book Page 137 Saturday, July 16, 2005 12:57 PM 138 CHAPTER 6 Normalization The following statements summarize the functional equivalence between the ER model and normalized tables: 1. Within an entity. The level of normalization is totally dependent upon the interrelationships among the key and nonkey attributes. It could be any form from unnormalized to BCNF or higher. 2. Binary (or binary recursive) one-to-one or one-to-many relationship. Within the “child” entity, the foreign key (a replication of the pri- mary key of the “parent”) is functionally dependent upon the child’s primary key. This is at least BCNF, assuming that the entity by itself, without the foreign key, is already BCNF. 3. Binary (or binary recursive) many-to-many relationship. The intersec- tion table has a composite key and possibly some nonkey attributes functionally dependent upon it. This is at least BCNF. 4. Ternary relationship. a. one-to-one-to-one => three overlapping composite keys, at least BCNF b. one-to-one-to-many => two overlapping composite keys, at least BCNF c. one-to-many-to-many => one composite key, at least BCNF d. many-to-many-to-many => one composite key with three attributes, at least BCNF; in some cases it can be also 4NF, or even 5NF In summary, we observed that a good, methodical conceptual design procedure often results in database tables that are either normalized (BCNF) already, or can be normalized with very minor changes. 6.7 Literature Summary Good summaries of normal forms can be found in Date [1999], Kent [1983], Dutka and Hanson [1989], and Smith [1985]. Algorithms for nor- mal form decomposition and synthesis techniques are given in Bern- stein [1976], Fagin [1977], and Maier [1983]. The earliest work in normal forms was done by Codd [1970, 1974]. Teorey.book Page 138 Saturday, July 16, 2005 12:57 PM 139 7 An Example of Logical Database Design he following example illustrates how to proceed through the require- ments analysis and logical design steps of the database life cycle, in a practical way, for a relational database. 7.1 Requirements Specification The management of a large retail store would like a database to keep track of sales activities. The requirements analysis for this database led to the six entities and their unique identifiers shown in Table 7.1. The following assertions describe the data relationships: • Each customer has one job title, but different customers may have the same job title. • Each customer may place many orders, but only one customer may place a particular order. • Each department has many salespeople, but each salesperson must work in only one department. • Each department has many items for sale, but each item is sold in only one department. (“Item” means item type, like IBM PC). T Teorey.book Page 139 Saturday, July 16, 2005 12:57 PM 140 CHAPTER 7 An Example of Logical Database Design • For each order, items ordered in different departments must involve different salespeople, but all items ordered within one department must be handled by exactly one salesperson. In other words, for each order, each item has exactly one salesperson; and for each order, each department has exactly one salesperson. For physical design (e.g., access methods, etc.) it is necessary to determine what kind of processing needs to be done on the data; that is, what are the queries and updates needed to satisfy the user require- ments, and what are their frequencies? In addition, the requirements analysis should determine whether there will be substantial database growth (i.e., volumetrics); in what time frame that growth will take place; and whether the frequency and type of queries and updates will change, as well. Decay as well as growth should be estimated, as each will have significant effect on the later stages of database design. 7.1.1 Design Problems 1. Using the information given and, in particular, the five assertions, derive a conceptual data model and a set of functional dependen- cies (FDs) that represent all the known data relationships. 2. Transform the conceptual data model into a set of candidate SQL tables. List the tables, their primary keys, and other attributes. 3. Find the minimum set of normalized (BCNF) tables that are func- tionally equivalent to the candidate tables. Table 7.1 Requirements Analysis Results Entity Entity key in characters Key length(max) Number of occurrences Customer cust-no 6 80,000 Job job-no 24 80 Order order-no 9 200,000 Salesperson sales-id 20 150 Department dept-no 2 10 Item item-no 6 5,000 Teorey.book Page 140 Saturday, July 16, 2005 12:57 PM 7.2 Logical Design 141 7.2 Logical Design Our first step is to develop a conceptual data model diagram and a set of FDs to correspond to each of the assertions given. Figure 7.1 presents the diagram for the ER model, and Figure 7.2 shows the equivalent diagram for UML. Normally, the conceptual data model is developed without knowing all the FDs, but in this example the nonkey attributes are omit- ted so that the entire database can be represented with only a few state- ments and FDs. The result of this analysis, relative to each of the asser- tions given, follows in Table 7.2. The candidate tables required to represent the semantics of this problem can be derived easily from the constructs for entities and rela- tionships. Primary keys and foreign keys are explicitly defined. Figure 7.1 Conceptual data model diagram for the ER model N N1 1 1 N N N N11 1 N 1 Customer SalespersonOrder Job Department Item order- item-sales contains has order- dept-sales places hires Teorey.book Page 141 Saturday, July 16, 2005 12:57 PM . Database Design he following example illustrates how to proceed through the require- ments analysis and logical design steps of the database life cycle, in a practical way, for a relational database. . relationship. a. one-to-one-to-one => three overlapping composite keys, at least BCNF b. one-to-one-to-many => two overlapping composite keys, at least BCNF c. one-to-many-to-many => one composite key,. growth should be estimated, as each will have significant effect on the later stages of database design. 7.1.1 Design Problems 1. Using the information given and, in particular, the five assertions, derive