Data Modeling and Database Design

2nd Edition Umanath Solutions Manual

Visit to download the full and correct content document: https://testbankdeal.com/dow
nload/data-modeling-and-database-design-2nd-edition-umanath-solutions-manual/
Data Modeling and Database Design 7-1

Chapter 7 – Functional Dependencies

Chapter 7 Objectives
After completing this chapter, the student will understand:
• What constitutes a functional dependency between attributes
• How to identify data redundancies in a relation schema
• How it is possible to eliminate data redundancies in a relation schema by
decomposing the relation schema into a series of relation schemas
• Armstrong’s axioms – Inference rules for functional dependencies
• The use of Armstrong’s axioms to derive the minimal cover for a set of functional
dependencies
• How to compute the closure of a set of attributes
• How to use the methods of synthesis and decomposition to derive candidate keys
• The distinction between prime and non-prime attributes

Chapter 7 Overview

Normalization, the topic of the next chapter (Chapter 8), is a technique that facilitates
systematic validation of participation of attributes in a relation schema from a perspective
of data redundancy. The building block that enables a scientific analysis of data
redundancy and the elimination of anomalies caused by data redundancy through the
process of normalization is called functional dependency. Chapter 7 introduces the
concept of functional dependency and how this concept can be used to scientifically
evaluate the “goodness” of a conceptual/logical design from the perspective of data
redundancy. Topics covered include a definition of functional dependency, a discussion of
inference rules that govern functional dependencies called Armstrong’s axioms, and the
idea of a minimal cover for a set of functional dependencies. Applications of Armstrong’s
axioms to systematically derive the candidate keys of a relation schema, given a set of
functional dependencies that hold on the relation schema, are also presented.
Data Modeling and Database Design 7-2

Chapter 7 Key Terms

Relation instance (Definition 1) A specially prepared relation state r of R

that conforms to the set of functional
dependencies specified on R and can be
used to infer the functional dependencies in
R.
Relation instance (Definition 2) A representative state that fully represents
all the characteristics of the source relation.
Insertion anomaly Occurs as a result of redundancy in the
relation schema when the insertion of a
tuple violates the entity integrity constraint.
Deletion anomaly Occurs as a result of redundancy in the
relation schema when the deletion of a
tuple also results in the inadvertent loss of
other data.
Update anomaly Occurs as a result of redundancy in the
relation schema when the update of one
tuple necessitates the need to update other
tuples in order to maintain the consistency
of the data in the database.
Modification anomalies An umbrella term that refers to insertion,
deletion, and update anomalies in a relation
schema caused by undesirable functional
dependencies.
Controlled redundancy A situation where some data redundancy is
tolerated as a tradeoff for efficiency of data
retrieval.
Normalization A technique that facilitates systematic
validation of the participation of attributes
in a relation schema from the perspective
of data redundancy.
Reverse engineer The process of going from a lower level of
abstraction (e.g., a relational schema) to a
higher level of abstraction (e.g., a Design-
specific ER diagram).
Functional dependency A constraint in a relation schema of the
form A  B where an attribute in B
(atomic or composite) is dependent on
attribute A (atomic or composite), if each
value, a, of A is associated with exactly one
value, b, of B.
Determinant The left side of a functional dependency.
Dependent The right side of a functional dependency.
Data Modeling and Database Design 7-3

F The collection of functional dependencies

in a relation schema that are semantically
obvious from the business rules.
F+ (or Closure) The set of functional dependencies stated in
F plus all other functional dependencies
that can be inferred from F.
Armstrong’s axioms The set of inference rules that can be used
to derive precisely the closure F+.
Reflexivity rule An inference rule stating that a set of
attributes always determines itself or any of
its subsets. In other words, if Y is a subset
of X (e.g., if X is {A,B,C,D} and Y is
{A,C}), then X→Y. Note: The reflexivity
rule defines what is called a trivial
dependency.
Augmentation rule An inference rule stating that adding the
same set of attributes is added to the left
and right sides of a functional dependency
results in a valid functional dependency. In
other words, if X→ Y, then
{X,Z}→{Y,Z}; also, {X,Z}→Y.
Transitivity rule An inference rule based on the logic that if
X implies Y and Y implies Z, then X
implies Z. In other words, if X→Y, and
Y→Z, then X→Z.
Decomposition rule An inference rule that allows for the
removal of attributes from the right side of
the functional dependency. In other words,
if X→{Y,Z}, then X→Y and X→Z.
Union (or additive) rule An inference rule that allows for the
combination of a set of functional
dependencies into a single functional
dependency. In other words, if X→Y, and
X→Z, then X→{Y,Z}.
Composition rule An inference rule that allows for the
combination of a set of non-overlapping
functional dependencies to form another
valid functional dependency. In other
words, if X→Y, and Z→W, then
{X,Z}→{Y,W}.
Pseudotransitivity rule An inference rule based on the logic that if
X implies Y and {Y,W} implies Z, then
{X,W} implies Z. In other words, if X→Y,
and {Y,W}→Z, then {X,W}→Z.
Data Modeling and Database Design 7-4

Canonical (or minimal) cover of F The set of functional dependencies, known

as Fc, where the redundant (extraneous)
functional dependencies in F have been
eliminated.
Prime attribute An attribute, atomic or composite, in a
relation schema, R, that is a proper subset
of the primary key of R.
Non-prime attribute An attribute in a relation schema, R, that is
not a member of the primary key.
Alternate key Any candidate key of R not chosen as the
primary key.

Chapter 7 Solutions

1. What is the purpose of the normalization technique in the data modeling process?
Answer. The purpose of the normalization technique is the systematic validation of
the participation of attributes in a relation schema from a perspective of data
redundancy.

2. Explain why data redundancy exists for the attributes Discount and Location in the
STOCK table in Figure 7.1c.
Answer. Data redundancy is defined as the superfluous repetition of data that does
not add new meaning. The simple appearance of duplication of data does not
necessarily imply data redundancy. The location of a store in STOCK is always the
same irrespective of any other fact in the table. Therefore, repetition of the value of
Location for every occurrence of Store value is a superfluous repetition and entails
data redundancy. Likewise, the discount associated with a specific quantity in
STOCK is always the same irrespective of any other fact in the table. Thus, repetition
of the same value of Discount every time a specific value of Quantity occurs does not
add any new meaning and so entails data redundancy.

3. Explain functional dependency between two attributes.

Answer. An attribute A (atomic or composite) in a relation schema R functionally
determines another attribute B (atomic or composite) in R if for a given value a1 of A
there is a single, specific value b1 of B in every relation state ri of R where r
represents all possible state (instances) of R. A symbolic expression of this FD is: A
 B.

In other words, in the context of the relation state STOCK in Figure 7.1c, Store 
Location since each individual value of Store is always associated with one and only
one individual value of Location. On the other hand, Location Not  Store since
each value of Location is not always associated with one and only one individual
value of Store.
Data Modeling and Database Design 7-5

4. Why can functional dependency not be inferred from a particular relation state?
Answer. A functional dependency is a property of the semantics (meaning) of the
relationship among attributes emerging from the business rules. That is, a functional
dependency is a property of the relation schema R, not of a particular relation state r
of R. Therefore, a functional dependency cannot be automatically inferred from any
relation state r of R (e.g., such as STOCK in Figure 7.1). It must be explicitly
specified as a constraint, and the source for this specification is the business rules of
the application domain. Thus, in the context of STOCK in Figure 7.1c, Store 
Location if and only if there is a business rule specifying that each store exists in one
and only one location. Likewise, while Quantity  Discount is true regardless of the
store in Figure 7.1c, unless this constraint is part of a business rule, this functional
dependency would not exist. A relation state, r of R, willfully constructed to represent
the specified business rules (FDs) is labeled as an “instance” of R in this book.

5. Identify the set of functional dependencies in the relation instance CAR shown below.
Does this constitute the minimal cover for the set of functional dependencies present
in CAR? If it is not a minimal cover, derive a minimal cover.

CAR
Model #cylinders Origin Tax Fee
Camry 4 Japan 15 30
Mustang 6 USA 0 45
Fiat 4 Italy 18 30
Accord 4 Japan 15 30
Century 8 USA 0 60
Mustang 4 Canada 0 30
Monte Carlo 6 Canada 0 45
Civic 4 Japan 15 30
Mustang 4 Mexico 15 30
Mustang 6 Mexico 15 45
Civic 4 Korea 15 30

Answer.
Since it is stated that the data above reflects an “instance” of a relation CAR, the
following set of semantically obvious FDs, F, are listed based on an assumed set of
business rules honoring the relationships reflected in the instance of CAR above.

F [fd1, fd2, fd3, fd4, fd5] where

fd1: Origin  Tax; fd2: (Model, #cylinders, Origin)  Fee; fd3: #cylinders  Fee;
fd4: Fee  #cylinders; fd5: {Model, #cylinders, Origin}  Tax

F, above, will be a minimal cover, Fc, only if (F – fdx for x = 1,2,3,4,5) is not equivalent to
F. That is, there are no redundant attributes or redundant FDs in F. Given F, it can
be seen that fd2 and fd5 are redundant FDs in F. Therefore, F is not a minimal cover
for F.
Data Modeling and Database Design 7-6

Fc [fd1, fd3, fd4] is a minimal cover for F. F can be derived from Fc and further
reduction of Fc will yield a set of FDs that is not equivalent to Fc and F.

6. What is the difference between F, F+ , and Fc?

Answer. F is the set of functional dependencies that are explicitly specified
(semantically obvious from the source business rules) on a relation schema. F+, on
the other hand, consists of all possible functional dependencies that can be inferred
from the set F. Known as the closure of F, F+ includes the set of functional
dependencies stated in F plus all other functional dependencies that can be inferred
from F. Fc is called the canonical cover or minimal cover for F. Fc is not only
equivalent to F (i.e., has the same closure as F), but any further reduction of Fc will
destroy this equivalence. In short, Fc is a simplified set of FDs equivalent to F.

7. What is the purpose of Armstrong’s axioms?

Answer. Armstrong’s axioms are a set of three inference rules and an additional set
of four useful inference rules that can be constructed from the basic three pertaining
to functional dependencies that are used to derive the closure of F (i.e., F+) as well as
the minimal cover of F (i.e., Fc).

8. Suppose F {fd1, fd2} consists of the following functional dependencies:

fd1: Ssn  {Ename, Bdate, Address, Dnumber}

fd2: Dnumber  {Dname, Dmgrssn}

Which of Armstrong’s axioms allows the following additional functional

dependencies to be inferred?

a. Ssn  {Dname, Dmgrssn}

b. Ssn  Ssn
c. Dnumber  Dname
d. Ssn  Dname

Answer
a. Rule of Decomposition (Ssn  Dnumber) and Rule of Transitivity (Ssn  Dnumber
 {Dname, Dmgrssn})
b. Rule of Reflexivity
c. Rule of Decomposition
d. Rule of Decomposition (Ssn  Dnumber and Dnumber  Dname) and Rule of
Transitivity (Ssn  Dnumber  Dname)

9. Why is it useful to know all the candidate keys of a relation schema?

Answer. One can make a best-informed choice of the primary key. Also, inadvertent
normalization errors (where an alternate key – i.e., a candidate key not chosen as the
primary key – is a determinant in a FD) can be avoided.
Data Modeling and Database Design 7-7

10. Describe the two approaches used in this book to derive candidate keys.
Answer. The two approaches for deriving candidate keys for a relation schema are
the synthesis approach and the decomposition approach. The synthesis approach is
based on the principle of the closure of an attribute set and seeks to derive an
irreducible set of attributes whose closure is precisely all attributes of the URS
(universal relation schema). The decomposition approach starts with a URS and the
set of functional dependencies F that prevails over the URS, and systematically
reduces the superkey until it is further irreducible under F. This irreducible superkey
is a candidate key of the relation schema. After one candidate key is derived using
either of these approaches, the method used to derive the rest of the candidate keys of
the relation schema is the same (see Tables 7.2 and 7.3 for the respective
procedures).

11. What is the difference between (a) a prime attribute and a non-prime attribute and (b)
a key and non-key attribute?
Answer. A prime attribute is any attribute, atomic or composite, in a relation schema
R that is a proper subset of the primary key of R. An attribute of R that is not a subset
of the primary key in a non-prime attribute except when it is a candidate key of R. A
candidate key is neither a prime attribute nor a non-prime attribute; given a primary
key of R, it is an alternate key of R. A key attribute is an attribute, atomic or
composite, in a relation schema R that is a proper subset of any candidate key of R.
Attributes that are not subsets of a candidate key of R are non-key attributes.

12. Given R (X, A, Z, B) and A  {B, Z}, what is the candidate key(s) of R?
Answer. The only candidate key of R is {A, X}

13. Consider the universal relation schema INVENTORY (Store#, Item, Vendor, Date,
Cost, Units, Manager, Price, Sale, Size, Color, Location) and the constraint set F
{fd1, fd2, fd3, fd4, fd5, fd6, fd7} where:

fd1: {Item, Vendor}  Cost fd2: {Store#, Date}  {Manager, Sale}

fd3: {Store#, Item, Date}  Units fd4: Manager  Store#
fd5: Cost  Price fd6: Item  {Size, Color}
fd7: Vendor  Location

a. Do the functional dependencies shown constitute a minimal cover of F? If not, do

they derive a minimal cover?

The algorithm to compute the minimal cover for a given set of functional
dependencies F is:
a. Set G to F.
b. Convert all FDs in G to standard (canonical) form—i.e., the right side
(dependent attribute) of every FD in G should be a singleton attribute.
c. Remove all redundant attributes from the left side (determinant) of the FDs in
G.
d. Remove all redundant FDs from G.
Data Modeling and Database Design 7-8

Accordingly, G in standard form is:

fd1: {Item, Vendor}  Cost
fd2b: {Store#, Date}  Sale
fd4: Manager  Store#
fd6a: Item  Size
fd7: Vendor  Location
fd2a: {Store#, Date}  Manager
fd3: {Store#, Item, Date}  Units
fd5: Cost  Price
fd6b: Item  Color

A systematic inspection of the standard form FDs above indicates that there are
no redundant attributes in the determinants of the FDs above, nor are there any
redundant FDs. Thus, G ( equivalent to F) is a minimal cover (Fc) for F.

b. Derive the candidate key(s) of URS using the synthesis approach.

The principle underlying the synthesis approach to deriving the candidate keys of
a URS is to condense a minimum set of attributes in URS whose attribute closure
is the URS – i.e., all attributes of URS. The heuristics specified in Table 7.2 offer
a step-by-step procedure to accomplish this. Note that a minimal cover (Fc) of F
that prevails over URS is the basis for this derivation. So, given Fc, as per the
heuristics stated in table 7.2, the following steps ensue:

The target determinant, TD1, the determinant of an FD with the most number of
attributes as its determinant, is:
{Store#, Item, Date}

The attribute closure, TD1+ (TD1 | Fc), is {Store#, Item, Date, Manager, Sale,
Units, Size, Color}.
Since TD1+ is not precisely the set of all attributes in URS, TD1, {Store#, Item,
Date} cannot be a candidate key of URS.

Now, selecting the determinant of an FD from Fc which is not a subset of TD1,

we have Td2 = {Item, Vendor}.

The attribute closure, TD2+ (TD2 | Fc), is {Item, Vendor, Cost, Price, Size, Color,
Location}. Since TD2+ is not precisely the set of all attributes in URS, TD2
{Item, Vendor} cannot be a candidate key of URS either.

TD1+ U TD2+ = {Store#, Item, Date, Manager, Sale, Units, Size, Color} U
{Item, Vendor, Cost, Price, Size, Color, Location}, which is precisely the set of
all the attributes in URS. Therefore, we have TD1 U TD2 as the first candidate
key of URS – i.e., {Store#, Item, Vendor, Date} is a candidate key of
INVENTORY.

Having derived one candidate key of INVENTORY, following steps 7 through 9

in Table 7.2,, we note that since Manager  Store# (fd4), {Manager, Item,
Vendor, Date} is another candidate key of INVENTORY.
Data Modeling and Database Design 7-9

It is easy to observe that there are no other candidate keys for INVENTORY | F.

c. Derive the candidate key(s) of URS by using the decomposition approach.

The principle underlying the decomposition approach is that since a relation

schema by definition must have a superkey, the set of all attributes, K, in URS is,
for starters, a superkey of URS. The task then is to systematically purge K of
attributes such that the reduced K, say, K’ remains a superkey of URS | Fc. This
step is repeated until K’ is further irreducible. The irreducible K’ is a candidate
key of URS. This algorithm is shown in table 7.3.

Accordingly, {Store#, Item, Vendor, Date, Cost, Units, Manager, Price, Sale, Size,
Color, Location} is a superkey, K, of INVENTORY.

Proceeding arbitrarily from left to right, removing Store# from K, we have

’
K = {K – Store#} = {Item, Vendor, Date, Cost, Units, Manager, Price, Sale, Size,
Color, Location}

K’ remains a superkey of INVENTORY since Manager  Store# (fd4) is in Fc and

the determinant of fd4, Manager is a subset of K’. That is, {K – Store#}  Store#.

Next, removal of Item from the current K’ will result in {K’ – Item} not  Item
since Item is not a dependent in any FD in Fc. Thus, the resulting new K’ will
not be a superkey of INVENTORY. So, Item cannot be removed from K’.
Likewise, Vendor and Date also cannot be removed from K’.

Next in line, removing Cost and Units from K’, we have

’’ ’
K = {K – (Cost, Units)} = {Item, Vendor, Date, Manager, Price, Sale, Size, Color,
Location}.
K’’ remains a superkey of INVENTORY since: {Item, Vendor}  Cost (fd1) and
{Store#, Item, Date}  Units (fd3) are in Fc and the determinants of fd1 and fd3, are
subsets of K’. That is, {K’ – (Cost, Units)}  {Cost, Units}.

Removal of Manager from the current K’’ will result in {K’’ – Manager} not 
Manager. Observe that Manager is a dependent in fd2a in Fc. Nonetheless, Store#,
part of the determinant in fd2a, is no longer present in the current K’’. Thus, the
new K’’ excluding Manager will not be a superkey of INVENTORY. So, Manager
cannot be removed from K’’.

Next, removing Price, Sale, Size, Color, Location from K’’, we have
’’’ ’’
K = {K – (Price, Sale, Size, Color, Location)} = {Item, Vendor, Date, Manager}.
K’’’ remains a superkey of INVENTORY since {K’’ – (Price, Sale, Size, Color,
Location)}  { Price, Sale, Size, Color, Location}.

Since further reduction of K’’’ = {Item, Vendor, Date, Manager} will not yield a
superkey of INVENTORY | Fc, {Item, Vendor, Date, Manager} is, by definition, a
candidate key of INVENTORY.
Data Modeling and Database Design 7-10

Derivation of additional candidate keys is the same as done in the synthesis

approach. Accordingly, the second candidate key of INVENTORY will be {Item,
Vendor, Date, Store#}.

14. Given the set of functional dependencies F {fd1, fd2, fd3, fd4, fd5, fd6, fd7, fd8, fd9,
fd10} where:

fd1: Tenant#  {Name, Job, Phone#, fd2: Job  Salary

Address}
fd3: Name  Gender fd4: Phone#  Address
fd5: {Name, Phone#}  {Tenant, Deposit} fd6: County  Tax_rate
fd7: Area  {Rent, County} fd8: Survey#  Lot
fd9: {Lot, County}  {Survey#, Area} fd10: {Survey#, Area}  County

a. Construct the universal relation schema that includes (i.e., preserves) the set of
functional dependencies in F.

URS (Tenant#, Name, Job, Phone#, Address, Salary, Gender, Deposit, County,
Tax_rate, Area, Rent, Survey#, Lot)

b. Do the functional dependencies shown constitute a minimal cover of F? If not,

derive a minimal cover.

Following the algorithm prescribed to derive a minimal cover for a set of FDs, F
(see Section 7.2.3.2, p. 370), it can be shown that {F – fd: Tenant#  Address} in
this case is a minimal cover, Fc, for F.

c. Derive the candidate key(s) of F.

Using the decomposition approach to deriving a candidate key (see Table 7.3, pp.
379 - 380),

{Tenant#, Name, Job, Phone#, Address, Salary, Gender, Deposit, County, Tax_rate,
Area, Rent, Survey#, Lot} is a superkey, K, of URS.

Next, arbitrarily starting at the right end of the URS, {K – Lot}  Lot | Fc, since Fc,
includes fd8: Survey#  Lot. Therefore, K’ = {Tenant#, Name, Job, Phone#, Address,
Salary, Gender, Deposit, County, Tax_rate, Area, Rent, Survey#}, is a superkey of
URS.

Next in line for removal, since we have arbitrarily chosen to work from the right,
is Survey#. But, {K’ – Survey#} not  Survey# | Fc. Therefore, Survey# must
remain in K’ in order for it to remain a superkey of URS.
Data Modeling and Database Design 7-11

’ ’
{K – Rent}  Rent | Fc while {K – Area} not  Area | Fc. Accordingly, we have a
reduced superkey of URS K’’where K’’ = {Tenant#, Name, Job, Phone#, Address,
Salary, Gender, Deposit, County, Tax_rate, Area, Survey#}.

Continuing to work from right to left, we see that Tax_rate, County, Deposit,
’’
Gender, Salary, Address, Phone#, Job, and Name can be purged from K without
sacrificing the superkey status of the reduced K’’. Accordingly, we have,
K’’’ = {Tenant#, Area, Survey#}, a further reduced superkey of URS – i.e.,
’’
{Tenant#, Area, Survey#}  URS | Fc. Since further reduction of K without
sacrificing its superkey status is impossible, K’’’ is a candidate key of URS.

Following Steps 4 through 6 in Table 7.3, the rest of the candidate keys of URS
can be derived as follows:

Since fd5a: {Name, Phone#}  Tenant# is in F, {Name, Phone#, Area, Survey#} is

another candidate key of URS | F.
Since fd9: {Lot, County}  {Survey#, Area} is in F, {Tenant#, Lot, County} and
{Name, Phone#, Lot, County} are also candidate keys of URS | F.
Since fd8 Survey#  Lot is in F, {Tenant#, Survey#, County} and {Name, Phone#,
Survey#, County} are also candidate keys of URS | F.
Since fd7b: Area  County is in F, {Tenant#, Lot, Area} and {Name, Phone#, Lot,
Area} are also candidate keys of URS | F.

d. Select the primary key and justify your choice.

{Tenant#, Area, Survey#} and {Tenant#, Lot, County} seem equally viable as the
primary key of URS. Both have the least number of attributes constituting the set,
and based on the FDs in F, the attributes in these two sets seem to be most
reflective of user-specified business rules conveyed through the FDs.
So, let us say that {Tenant#, Lot, County}

e. Considering your primary key and candidate key(s), distinguish between (1) key
versus non-key attributes and (2) prime versus non-prime attributes.

URS (Tenant#, Name, Job, Phone#, Address, Salary, Gender, Deposit, Lot, County,
Tax_rate, Area, Rent, Survey#,)

Role of the Attribute

Attribute Key/Non-key Attribute Prime/Non-prime Attribute

Tenant# Key attribute Prime attribute

Name Non-key attribute Non-prime attribute

Job Non-key attribute Non-prime attribute

Phone# Non-key attribute Non-prime attribute

Data Modeling and Database Design 7-12

{Name, Phone#} Key attribute Non-prime attribute

Address Non-key attribute Non-prime attribute

Salary Non-key attribute Non-prime attribute

Gender Non-key attribute Non-prime attribute

Deposit Non-key attribute Non-prime attribute

Lot Key attribute Prime attribute

County Key attribute Prime attribute

{Lot, County} Key attribute Prime attribute

Tax_rate Non-key attribute Non-prime attribute

Area Key attribute Non-prime attribute

Rent Non-key attribute Non-prime attribute

{Rent, County} Non-key attribute Non-prime attribute

Survey# Key attribute Non-prime attribute

{Survey#, Area} Key attribute Non-prime attribute

{Tenant#, Survey#, Area} Candidate key Alternate key

{Name, Phone#, Survey#, Area} Candidate key Alternate key

{Tenant#, Lot, County} Candidate key Primary key

{Name, Phone#, Lot, County} Candidate key Alternate key

{Tenant#, Lot, Area} Candidate key Alternate key

{Name, Phone#, Lot, Area} Candidate key Alternate key

{Tenant#, Survey#, County} Candidate key Alternate key

{Name, Phone#, Survey#, County} Candidate key Alternate key

Note: Any composite attribute that includes one or more non-key attribute(s) is a non-key attribute.

15. Given the set of functional dependencies F {fd1, fd2, fd3, fd4, fd5, fd6, fd7, fd8, fd9,
f10, f11} where:

fd1: Client  Office fd2: Stock  {Exchange, Dividend}

fd3: Broker  Profile fd4: Company  Stock
fd5: Client  {Risk_profile, Analyst} fd6: Analyst  Broker
Data Modeling and Database Design 7-13

fd7: {Stock, Broker}  {Investment, Volume} fd8: Stock  Company

fd9: Investment  {Commission, Return} fd10: {Stock, Broker}  Client
fd11: Account  Assets

a. Construct the universal relation schema that includes (i.e., preserves) the set of
functional dependencies in F.

URS (Client, Office, Stock, Exchange, Dividend, Broker, Profile, Company,

Risk_profile, Analyst, Investment, Volume, Commission, Return, Account, Assets)

b. Do the functional dependencies shown constitute a minimal cover of F? If not,

derive a minimal cover.

Following the algorithm prescribed to derive a minimal cover for a set of FDs, F
(see Section 7.2.3.2, p. 320), it can be shown that F in this case is a minimal
cover, Fc, for F since there are no redundant attributes or redundant FDs in F.

c. Derive the candidate key(s) of F.

Let us arbitrarily choose to use the synthesis approach to the derivation of

candidate key(s). The principle underlying the synthesis approach to deriving the
candidate keys of a URS is to condense a minimum set of attributes in URS
whose attribute closure is the URS – i.e., all attributes of URS. The heuristics
specified in Table 7.2 offer a step-by-step procedure to accomplish this. Note that
a minimal cover (Fc) of F that prevails over URS is the basis for this derivation.
So, given Fc, as per the heuristics stated in table 7.2, the following steps ensue:

The target determinant, TD1, the determinant of an FD with the most number of
attributes as its determinant, is:
{Stock, Broker}

The attribute closure, TD1+ (TD1 | Fc), is, through multiple iteration through Fc,
{Stock, Broker, Exchange, Dividend, Profile, Investment, Volume, Company, Client,
Office, Risk_profile, Analyst, Commission, Return}.
Since TD1+ is not precisely the set of all attributes in URS, TD1, {Stock, Broker}
cannot be a candidate key of URS.

Now, selecting the determinant of an FD from Fc that is not a subset of TD1, we

have Td2 = Account.

The attribute closure, TD2+ (TD2 | Fc), is {Account, Assets}. Since TD2+ is not
precisely the set of all attributes in URS, TD2, Account cannot be a candidate key
of URS either.
TD1+ U TD2+ = {Stock, Broker, Exchange, Dividend, Profile, Investment, Volume,
Company, Client, Office, Risk_profile, Analyst, Commission, Return} U {Account,
Data Modeling and Database Design 7-14

Assets} which is precisely the set of all the attributes in URS. Therefore, we have
TD1 U TD2 as the first candidate key of URS – i.e., {Stock, Broker, Account} is a
candidate key of URS | F.

Having derived one candidate key of URS, following Steps 7 through 9 in Table
7.2, the other candidate keys, if any, can be derived as follows.

Since fd4: Company  Stock is in F, {Company, Broker, Account} is another

candidate key of URS | F.

Since fd6: Analyst  Broker is in F, {Stock, Analyst, Account} and {Company,

Analyst, Account} are also candidate keys of URS | F.

Since fd5b: Client  Analyst is in F, {Stock, Client, Account} and {Company,

Client, Account} are also candidate keys of URS | F.

It is easy to observe that there are no other candidate keys for URS | F.

d. Select the primary key and justify your choice.

Based on the FDs in F, the attributes Stock and Broker seem to be most reflective
of user-specified business rules conveyed through these FDs. Accordingly,
{Stock, Broker, Account} seems to be the semantically ideal choice for the primary
key of URS.

e. Considering your primary key and candidate key(s), distinguish between (1) key
versus non-key attributes and (2) prime versus non-prime attributes.

URS (Client, Office, Stock, Exchange, Dividend, Broker, Profile, Company,

Risk_profile, Analyst, Investment, Volume, Commission, Return, Account, Assets)

Role of the Attribute

Attribute Key/Non-key Prime/Non-prime
Attribute Attribute

Client Key attribute Non-prime attribute

Office Non-key attribute Non-prime attribute
Stock Key attribute Prime attribute
Exchange Non-key attribute Non-prime attribute
Dividend Non-key attribute Non-prime attribute
{Exchange, Dividend} Non-key attribute Non-prime attribute
Data Modeling and Database Design 7-15

Broker Key attribute Prime attribute

Profile Non-key attribute Non-prime attribute
Company Key attribute Non-prime attribute
Risk_profile Non-key attribute Non-prime attribute
Analyst Key attribute Non-prime attribute
Investment Non-key attribute Non-prime attribute
Volume Non-key attribute Non-prime attribute
Commission Non-key attribute Non-prime attribute
Return Non-key attribute Non-prime attribute
Account Key attribute Prime attribute
Assets Non-key attribute Non-prime attribute
{Stock, Broker} Key attribute Prime attribute
{Stock, Broker, Account} Candidate key Primary key
{Company, Broker} Key attribute Non-prime attribute
{Company, Broker, Account} Candidate key Alternate key
{Stock, Analyst, Account} Candidate key Alternate key
{Company, Analyst, Account} Candidate key Alternate key
{Stock, Client, Account} Candidate key Alternate key
{Company, Client, Account} Candidate key Alternate key
Note: Any composite attribute that includes one or more non-key attribute(s) is a
non-key attribute.

16. Given the Universal Relation Schema URS (A, B, C, D, F, G) and the set of FDs prevailing
over URS F {fd1, fd2, fd3, fd4, fd5, fd6}, where:

fd1: A  G; fd2: {A, B}  {C, D}; fd3: {B, C}  {F, G};

fd4: G  B; fd3: {B, D}  A; fd5: C  G

a. Derive a canonical cover of F.

F expressed in standard form:

fd1: A  G; fd2a: {A, B}  C; fd2: {A, B}  D;

fd3a: {B, C}  F; fd3b: {B, C}  G; fd4: G  B;
fd5: {B, D}  A; fd6: C  G
Data Modeling and Database Design 7-16

Observe that based on fd1 and fd4 using the rule of transitivity (Armstrong’s axiom) we
infer that in fd2a B is redundant; therefore, we get fd2ax: A  C; likewise, we also can
derive fd2bx: A  D.

Next, based on fd6 and fd4, we can derive fd3ax: C  F because we can infer
here that in fd3a B is redundant.

Given fd2ax and fd6, it is seen that fd1 is redundant. Likewise, given fd6, fd3b
becomes a redundant fd.

Further application of the algorithm for deriving the canonical cover will clarify
that there are no more redundancies in F. Thus we have,

Fc {fd2ax, fd2bx, fd3ax, fd4, fd5, fd6}

fd2ax: A  C; fd2bx: A  D; fd3ax: C  F; fd4: G  B;

fd5: {B, D}  A; fd6: CG

b. Derive all the candidate keys of URS.

A; {B, D}; {G, D}; {C, D}

17. Given the Universal Relation Schema URS (A, B, C, G, W, X, Y, Z) and the set of FDs
prevailing over URS, F {fd1, fd2, fd3, fd4, fd5}, where:

fd1: B  G; fd2: {X, Z}  {Z, Y, B}; fd3: {Y, A}  {C, G};

fd4: C  W; fd5: {X, Z}  G;

a. Derive a canonical cover of F.

fd1: B  G ; fd2b: {X, Z}  Y ; fd2c: {X, Z}  B;

fd3a: {Y, A}  C; fd3b: {Y, A}  G; fd4: C  W

b. Derive the candidate key(s) of URS.

Candidate Key: {A, X, Z}
c. Is the fd {X, A, Z}  {W} in F+ ?
fd {A, X, Z}  {B, Y} is in F+ since {A, X, Z} is a candidate key of URS
d. Is the decomposition D {R1, R2}, where R1 (X, Z, Y, A, B) and R2 (A, C, Y, G, W), lossless?
This question can be answered only in chapter 8.
e. Is the decomposition D {R3, R4}, where R3 (X, Z, Y, A, C) and R4 (C, X, G, W, Z), lossless?
This question can be answered only in chapter 8.