4.2.1
Redundancy: The owner address is repeated in AccSets and Addresses entity sets. Simplicity: AccSets does not serve any useful purpose and the design can be more simply represented by creating many-to-many relationship between Customers and Accounts.
Right kind of element: The entity set Addresses has a single attribute address. A customer cannot have more than one address.
Hence address should be an attribute of entity set Customers.
Faithfulness: Customers cannot be uniquely identified by their names. In real world Customers would have a unique attribute such as ssNo or customerNo
4.2.2
Studios and Presidents can be combined into one entity set Studios with Presidents becoming an attribute of Studios under following circumstances:
1. The Presidents entity set only contains a simple attribute viz. presidentName. Additional attributes specific to Presidents might justify making Presidents into an entity set.
4.2.3
4.2.4 The entity sets should have single attribute. a) Stars: starName b) Movies: movieName
c) Studios: studioName. However there exists a many-to-many relationship between Studios and Contracts. Hence, in addition, we need more information about
studios involved. If a contract always involves two studios, two attributes such as producingStudio and starStudio can replace the
Studios entity set. If a contact can be associated with at most five studios, it may be possible to replace the Studios entity set by five attributes viz. studio1, studio2, studio3, studio4, and studio5. Alternately, a composite attribute containing concatenation of all studio names in a contact can be
considered. A separator character such as \of such an attribute using query like '%keyword%'
4.2.5
From Augmentation rule of Functional Dependency, given
B -> M (B=Baby, M=Mother) then
BND -> M (N=Nurse, D=Doctor)
Hence we can just put an arrow entering mother.
a) Put an arrow entering entity set Mothers for the simplest solution (As in fig. 4.4, where a multi-way relationship was allowed, even though Movies alone could identify the Studio). However, we can display more accurate information with below figure.
b)
c)
Again from Augmentation rule of Functional Dependency, given BM -> D then
BMN -> D
Thus we can just add an arrow entering Doctors to fig 4.15. Below figure represents more accurate information however.
4.2.6 a)
b) Transitivity and Augmentation rules of Functional Dependency allow arrow entering Mothers from Births. However, a new relationship in below figure represents more accurate information.
c)
Design flaws in abc above 1. As suggested above, using Transitivity and
Augmentation rules of Functional Dependency, much simpler design is possible.