6.6 Summary 137A 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 • 5
Trang 16.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
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 Name Normal Form
Two-way Lossless decomp/join?
Three-way Lossless decomp/join?
Nontrivial MVDs
skill_in_
common
Trang 2attributes 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
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]
Trang 37
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
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
Trang 4For 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
Entity
Entity key
in characters
Key length(max)
Number of
occurrences
Trang 57.2 Logical Design 141
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 represenomit-ted 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
N
1 1
N N
N
1
N
1
Customer
Salesperson Order
Job
Department
Item
order-item-sales
contains
has
order-dept-sales places
hires