Data Modeling and Database Design 2nd Edition Umanath Solutions Manual 1

Data Modeling and Database Design 6-1
Data Modeling and Database Design 2nd Edition Umanath

Full download at:
Solution Manual:
https://testbankpack.com/p/solution-manual-for-data-modeling-and-database-design-2nd-edition-
by-umanath-scamell-isbn-1285085256-9781285085258/
Chapter 6 – The Relational Data Model
Chapter 6 Objectives
After completing this chapter, the student will understand:
• The characteristics of a relation
• Data integrity constraints that pertain to the relational data model
• Some basic relational algebra operations
• The role of views and materialized views in the relational data model
• Problems caused by the lack of information preservation in data model mapping
• Two basic (popular) approaches to map ER and EER constructs to a logical schema
• An information-preserving grammar to map ER and EER constructs to a logical schema
• Mapping complex ER models to logical schema
Chapter 6 Overview
This chapter introduces the relational data model and the process of mapping a conceptual
schema that is technology-independent to a logical schema (in this case, a relational data model)
that provides the transition to a technology-dependent database design. The chapter begins with a
discussion of the characteristics of a relation and the data integrity constraints that accompany
the relational data model. This is followed by a brief introduction to relational algebra as a means
to specify the logic for data retrieval from a series of relations. The rest of the chapter discusses
mapping a conceptual schema to its logical counterpart in the context of several examples that
employ both an information-reducing mapping grammar and an information-preserving mapping
grammar.
Chapter 6 Key Terms
Relational algebra A series of data manipulation operations

performed on relations.
Relational data model The representation of a database as a
collection of relations.
Relation A two-dimensional table of values
presented as rows and columns.
Tuple A row in a relation that contains a set of
related data values.
Attribute Formal name for a column in a relation.
Relation schema (also known as a schema, A tuple that contains the attribute names
scheme, or intension) comprising a relation.
Relational schema A set of relation schemas in a relational
data model.
Extension The body of a relation.
Degree of a relation The number of attributes in a relation
schema.
Relation state A specific occurrence of a relation (or
should we say relation schema).
Cardinality of a relation The number of tuples in a relation state.
Declarative (or schema-based) constraint A constraint directly expressed in the
schema of the data model.
Application-based constraint A constraint that must be enforced through
application programming code.
State constraint A restriction that every valid state of the
database must satisfy.
Transition constraint A constraint that defines the legal
transitions of database states. For example,
the only valid states of transition from
“married” are “divorced,” “widowed,” or
“deceased.”
Superkey A set of one or more attributes, which
taken collectively, uniquely identifies a
tuple of a relation.
Superset A set S1 is a superset of another set S2 if
every element in S2 is in S1. S1 may have
elements that are not in S2.
Subset A set S2 is a subset of another set S1 if
every element in S2 is in S1. S1 may have
exactly the same elements as S2. If S2 is a
subset of S1, S1 is a superset of S2.
Proper subset A set S2 is a proper subset of another set S1
if every element in S2 is in S1 and S1 has
some elements which are not in S2.
Candidate key A superkey with no proper subsets that are

superkeys.
Uniqueness property The prohibition of the presence of identical
values for the collection of attribute(s) that
constitute a unique identifier.
Irreducibility property The requirement that no proper subset of a
candidate key have the uniqueness
property.
Primary key Chosen from among the candidate keys to
serve the role of uniquely identifying tuples
of a relation schema.
Entity integrity constraint A constraint that requires the primary key
of a relation schema to not contain a
missing (i.e., null) value.
Referential integrity constraint The requirement that a relation r2, that
refers to another relation r1, refers to a
tuple that exists in r1.
Foreign key constraint A type of referential integrity constraint
where it is necessary that every value of an
attribute A2, atomic or composite, in
relation r2 must either occur as the value of
the candidate key A1 in some tuple of the
relation r1 that r2 refers to or, if allowed,
be null.
Inclusion dependency A condition requiring that all values of
attribute A2 in relation to r2 appear in the
set of values A1 in relation r1. Note that if
the participation of r2 in its relationship
with r1 is partial, then A2 can have null
values.
Selection operation A relational algebra operation used to
create a second relation by extracting a
horizontal subset of tuples from a relation
that match specified search criteria.
Projection operation A relational algebra operation used to
create a second relation by extracting a
vertical subset of columns from a relation.
Union compatibility A requirement when forming the union,
intersection, or difference of two relations
that each relation be of the same degree and
that corresponding attributes in the two
relations come from (or share) the same
domain.
Union operation A relational algebra operation that adds the

tuples of two union compatible relations
together to create a third relation that
consists of tuples that are in either the first
relation or the second relation.
Difference operation A relational algebra operation that involves
two union compatible relations where the
tuples of one relation are subtracted from
tuples of the second relation to produce a
third relation that contains the tuples from
the second relation that are not in the first
relation.
Intersection operation A relational algebra operation that involves
two union compatible relations that
involves the creation of a third relation
containing tuples common to the two
relations.
Join operation A relational algebra operation that
combines two relations into a third relation
by matching values for attributes in the two
relations that come from the same domain.
Natural join operation A relational algebra join operation where
the third relation does not redundantly
carry the joining attributes.
View A named “virtual” relation schema
constructed from one or more relation
schemas through the use of one or more
relational algebra operations that serves as
a logical window to view selected data
(attributes and tuples) from one or a set of
relations.
Materialized view Also known as a snapshot, a materialized
view, unlike a view, is stored in the
database and refreshed when updates occur
to the relation schemas from which the
materialized view is generated.
Referencing relation schema In logical modeling, a relation schema that
contains a foreign key attribute.
Referenced relation schema In logical modeling, the relation schema
referenced by the foreign key contained in
the referencing relation schema.
Foreign key design A logical data modeling approach requiring
all non-null foreign key values match some
value of the referenced candidate key.
Cross-referencing design A logical data modeling approach used to

avoid creating a relation schema with null
values for the foreign key.
Mutual-referencing design A logical data modeling approach where
the two relation schemas directly reference
each other by placing foreign keys in both.
Chapter 6 Solutions
1. Define the terms, tuple, attribute, and relation.

Answer. In a relation, a tuple represents a set (i.e., a row) of related data values. A column of
a relation is referred to as an attribute. A relation is a two-dimensional table of values
presented as rows and columns. Another way to say this is that the set of all tuples in a table
is called a relation.
2. What is a relation schema? What is the difference between a relation, a relation schema, and
a relational schema?
Answer. A relation schema represents the basic structure of a relation. It consists of a name
along with a set of related attributes. When sets of values are assigned to the attributes that
make up a relation schema, a relation is created. In other words, a relation is a relation
schema with data. The terms “relation” and “relation schema” are typically used
interchangeably. A relational schema is a set of relation schemas. A relational schema is
another name for a relational data model (see footnote 1 at the bottom of page 245).
3. What is the difference between a derived attribute and a stored attribute in terms of their
representation in a relation schema?
Answer. Only stored attributes are captured in a relation schema.
4. What is a null value? What gives rise to null values in a relation?

Answer. A null value is missing value. Sometimes a null value arises because it is simply
unknown. For example, a person’s salary would be a null value if we simply did not know his
or her salary. On the other hand, a null value might be assigned to the commission attribute
of an employee with the job of accountant since typically only salespersons qualify for a
commission.
5. Distinguish between a subset and a proper subset?

Answer. Every element in a set of values is included in a subset. Consider the set of numbers
{1, 2, 3}. The subsets of {1, 2, 3} would be {1, 2, 3}, {1, 2}, {1, 3}, {2, 3}, {1}, {2}, and {3}.
On the other hand, the proper subsets of {1, 2, 3} would include all of the above with the
exception of the set itself.
6. What is a candidate key? How does a candidate key differ from a superkey?
Answer. A candidate key is defined as a superkey with no proper subsets that are superkeys.
A candidate key has two properties: the uniqueness property and the irreducibility property,
whereas a superkey possesses only the uniqueness property.
7. What is a primary key? How do the properties of a primary key differ from those of a
candidate key?
Answer. A primary key is a candidate key that in addition to having the uniqueness and
irreducibility properties also satisfies the entity integrity constraint (i.e., a primary key
cannot have a missing value).
8. Identify the superkeys, candidate key(s), and the primary key for the following relation
instance of the STU-CLASS relation schema.
Student Student Student Class Class

Number Name Major Name Time
0110 KHUMAWALA ACCOUNTING BA482 MW3
0110 KHUMAWALA ACCOUNTING BD445 TR2
0110 KHUMAWALA ACCOUNTING BA491 TR3
1000 STEDRY ANTHROPOLOGY AP150 MWF9
1000 STEDRY ANTHROPOLOGY BD445 TR2
2000 KHUMAWALA STATISTICS BA491 TR3
2000 KHUMAWALA STATISTICS BD445 TR2
3000 GAMBLE ACCOUNTING BA482 MW3
3000 GAMBLE ACCOUNTING BP490 MW4
Answer.
Superkey Candidate Key
Student Number N N
Student Name N N
Student Major N N
Class Name N N
Class Time N N
(Student Number, Student Name) N N
(Student Number, Student Major) N N
(Student Number, Class Name) Y Y
(Student Number, Class Time) Y Y
(Student Name, Student Major) N N
(Student Name, Class Name) N N
(Student Name, Class Time) N N
(Student Major, Class Name) N N
(Student Major, Class Time) N N
(Class Name, Class Time) N N
(Student Number, Student Name, Student Major) N N
(Student Number, Student Name, Class Name) Y N
(Student Number, Student Name, Class Time) Y N
(Student Number, Student Major, Class Name) Y N
(Student Number, Student Major, Class Time) Y N
(Student Number, Class Name, Class Time) Y N
(Student Name, Student Major, Class Name) N N
(Student Name, Student Major, Class Time) N N
(Student Name, Class Name, Class Time) N N
(Student Major, Class Name, Class Time) N N
(Student Number, Student Name, Student Major, Class Name) Y N
(Student Number, Student Name, Student Major, Class Time) Y N
(Student Number, Student Name, Class Name, Class Time) Y N
(Student Number, Student Major, Class Name, Class Time) Y N
(Student Name, Student Major, Class Name, Class Time) N N
(Student Number, Student Name, Student Major, Class Name, Class Time) Y N
9. Define the term referential integrity constraint. Why is referential integrity important? How
is the term foreign key used in the context of referential integrity?
Answer. Informally, a referential integrity constraint implies that a tuple in a relation, r2,
that refers to another relation, r1, refers to a tuple that exists in r1. In order to establish a
referential integrity constraint between the two relation schemas, R1 and R2, it is necessary
that every value of an attribute A2, atomic or molecular, in relation to r2 must either be null
or occur as the value of a candidate key in some tuple of the relation r1 that r2 refers to.
The attribute in R2 that meets this condition is called a foreign key of R2. R2 is called the
referencing relation schema and R1 is known as the referenced relation schema.
10. This exercise refers to the relations R1 and R2 given below. Show the relations created as a
result of the following relational algebra operations.
Relation R1 Relation R2
R1.a R1.b R1.c R2.x R2.y R2.z
30 a 20 30 b 24
45 b 32 75 c 12
75 a 24 30 b 20
Answer.
10a. The union of R1 and R2
Relation R3 – Result
R3.a R3.b R3.c
30 a 20
45 b 32
75 a 24
30 b 24
75 c 12
30 b 20
10b. The difference of R1 and R2

R3.a R3.b R3.c
30 a 20
45 b 32
75 a 24
10c. The difference of R2 and R1

R3.a R3.b R3.c
30 b 24
75 c 12
30 b 20
10d. The intersection of R1 and R2

There are no common tuples in R1 and R2 and thus the intersection does not exist.
10e. The natural join of R1 and R2. Assume that R1.a and R2.x are the joining attributes.
R3.a R3.b R3.c R3.y R3.z
30 a 20 b 24
30 a 20 b 20
75 a 24 c 12
11. Exercise 11 refers to the DRIVER, TICKET_TYPE, and TICKET relations given below.
DRIVER (Dr_license_no, Dr_name, Dr_city, Dr_state)

TICKET_TYPE (Ttp_offense, Ttp_fine)
TICKET (Tic_ticket_no, Tic_ticket_date, Tic_dr_license, Tic_ttp_offense)
An instance of each of these relations follows. Use the data shown below to (a) write the
answer to each question and (b) list the relational algebra operation(s) required to obtain the
answer.
Dr_license_no Dr_name Dr_city Dr_state
MVX 322 E. Mills Waller TX
RVX 287 R. Brooks Bellaire TX
TGY 832 L. Silva Sugarland TX
KEC 654 R. Lence Houston TX
MQA 823 E. Blair Houston TX
GRE 720 H. Newman Pearland TX
Ttp_offense Ttp_fine
Parking 15
Red Light 50
Speeding 65
Failure To Stop 30
Tic_Ticket_no Tic_ticket_date Tic_dr_license_no Tic_ttp_offense

1023 20-Dec-2007 MVX 322 Parking
1025 21-Dec-2007 RVX 287 Red Light
1397 03-Dec-2007 MVX 322 Parking
1027 22-Dec-2007 TGY 832 Parking
1225 22-Dec-2007 KEC 654 Speeding
1212 06-Dec-2007 MVX 322 Speeding
1024 21-Dec-2007 RVX 287 Speeding
1037 23-Dec-2007 MVX 322 Red Light
1051 23-Dec-2007 MVX 322 Failure To Stop
Answer.
11a. What are the names of all drivers?
E. Mills, R. Brooks, L. Silva, R. Lence, E. Blair, H. Newman
Requires a projection operation over the DRIVER relation on the Dr_name attribute.
PROJECT DRIVER OVER DRIVER.Dr_name GIVING ANSWER.
11b. What are the license numbers of all drivers who have been issued a ticket?
MVX 322, RVX 287, TGY 832, KEC 654
Requires a projection operation over the TICKET relation on the Tic_dr_license attribute.
PROJECT TICKET OVER TICKET.Tic_dr_license_no GIVING ANSWER.
11c. What are the license numbers of those drivers who have never been issued a ticket?
MQA 823, GRE 720
Requires taking the difference of projections the driver license number attribute in the DRIVER
and TICKET relations.
PROJECT DRIVER OVER DRIVER.Dr_license_no
MINUS
PROJECT TICKET OVER TICKET.Tic_dr_license_no GIVING ANSWER
11d. What are the names of all drivers who have been issued a ticket?
E. Mills, R. Brooks, L. Silva, R. Lence
Requires joining the DRIVER and TICKET relations over their common attribute driver license
number and then following this with a projection operation that projects out the name of
driver.
JOIN DRIVER AND TICKET OVER DRIVER.Dr_license_no, TICKET.Tic_dr_license_no
GIVING ANSWER
PROJECT ANSWER OVER ANSWER.Dr_name GIVING FINAL_ANSWER
12. What would cause a relational schema for a database to contain more relation schemas than
there are entity types?
Answer. This is somewhat of a trick question. A relational schema has the same number of
relation schemas as there are entity types as long as the Fine-granular Design-Specific ER
diagram serves as input.
13. Discuss the concept of information preservation in data model mapping.

Answer. The fundamental issue is that the process of transforming a conceptual model (in
our case a Fine-granular Design-Specific ER diagram supplemented by various semantic
integrity constraints) into a logical model that is based on the relational data model is
preserved in the information content of the business rules incorporated in the conceptual
model.
14. What is required to map a base entity type to a relation schema? Describe how this approach
differs for a weak entity type.
Answer. Four activities are required: (1) create a relation schema for each base entity type
in the Fine-granular Design-Specific ER diagram, (2) include the stored attributes
associated with the entity type in the relation schema, (3) in the case of composite attributes
record only the atomic components, and (4) underline the atomic attribute(s) that make up
the primary key. A weak entity type is mapped in a like manner except that the primary key of
the identifying parent of the weak entity type is added to the relation schema.
15. What is required to map a relationship type that exhibits a 1:n cardinality ratio?
Answer. Using the foreign key design, place the key (either the primary key or a candidate
key) of the parent as a foreign key attribute of the child.
16. What is the difference between the referencing relation schema and the referenced relation
schema? How are these terms incorporated into the foreign key design?
Answer. The parent is the referenced relation schema and the child is the referencing
relation schema (i.e., it references the relation schema that contains the primary key).
17. What is the purpose of the cross-referencing design?

Answer. The cross-referencing design is an alternative modeling approach that guarantees
the absence of null values in the foreign key. It entails the creation of a relation schema to
represent the relationship type.
18. What complicates the mapping of 1:1 cardinality ratios?

Answer. The fact that either one of the entity types engaged in the 1:1 relationship type can
be the parent or the child is what complicates the mapping of the 1:1 relationship type.
Three cases exist: (1) the participation constraint of one of the entity types participating in
the relationship type is total, and the other is partial, (2) the participation constraints of both
entity types in the relationship type are partial, or (3) the participation constraints of both
entity types in the relationship type are total.
19. Describe mutual referencing and the complexities that it introduces.

Answer. Mutual referencing (i.e., where a foreign key is added in both relation schemas
engaged in the relationship) between two relation schemas entails the specification of
additional constraints to ensure consistency maintenance. Such constraints can only be
implemented procedurally. One required constraint is that both foreign keys be unique in
order to maintain the cardinality ratio of 1:1. Total participation of both entity types in the
relationship type is incorporated in the design by not allowing null values for the foreign
keys. Two other complexities accompany the presence of foreign keys in both relation
schemas. First, procedural intervention is necessary to make sure that the
[primary/candidate key, foreign key] pairs in the two relations match. Second, the two
relation schemas referencing each other create a cycle necessitating that enforcement of at
least one of the referential integrity constraints be deferred to run time.
20. What information is lost by the use of the information-reducing grammar?

Answer. Use of the information-reducing grammar to transform a conceptual model to a
logical model results in loss of the following information:
a. Failure to distinguish between 1:1 and 1:n cardinality ratios
b. Failure to map the participation constraints of a relationship type
c. Failure to retain the optional/mandatory property of an attribute
d. Failure to identify alternate keys
e. Failure to recognize the composite nature of some collection of atomic attributes
f. Failure to carry forward derived attributes specified in the ER diagram
g. Failure to map deletion rules to the logical schema
h. Failure to carry forward the attribute type and size specified in the ER diagram
21. Describe how to map a specialization hierarchy, a specialization lattice, and a categorization.
Answer. Three different logical schema solutions are possible for mapping a specialization.
The first solution is to create one logical scheme for each of the subclasses and superclass in
the specialization. The second solution is the opposite of the first in that one logical scheme
is used to represent the entire specialization. The third solution involves incorporating the
attributes of the superclass in each of the individual logical schemes for the subclasses. It
should be noted that this approach cannot be used if the completeness constraint is partial.
a. Specialization hierarchy. Add the primary key of the superclass entity type as a foreign
key of the subclass entity type when mapping.
b. Specialization lattice. Add the primary key of each superclass entity type as a foreign key
of the subclass entity type.
c. Categorization. Add the primary key of the subclass entity type to each superclass entity
type.
22. What do you think are the ultimate consequences of failure to “preserve information” in the
data model mapping process?
Answer. Unless a complete mapping of all modeling constructs and constraints that are
inherent, implicit, or explicit in the source (i.e., conceptual) data model occurs in the target
(i.e., logical) data model, they will have to be handled in the logical design activity through
application programs, or the ultimate consequences will be acceptance of an information-
reducing transformation.
23. For the following excerpt from an ERD, specify the logical (relational) schema as per the
foreign key design in the following ways:
a. using directed arcs
b. in terms of inclusion dependencies
[A,1] [N,6]
[A,20] Base_salar
Mini [A,7]
Lnam y
t [N,2] Lic_plate
e
#
[A,20] Pct_commisio
Vin_num
Fname n
Name
[N,5.2]
Emp_no (0, n)
Sells (0, Msrp
1)
SALESPERSON VEHICLE
[A,1]
Gende [N,4]
r Model_y
r [A,13
[Dt,8] ]
Date_hire Make
d
Answer
a. Directed arc method:
From the answer to (b) given below, it is easy to draw the single directed arc.
b. inclusion dependencies technique:

SALESPERSON (Sls_empno, Sls_fname, Sls_minit, Sls_lname, Sls_pctcommission, Sls-basesalary, Sls_gender, Sls_datehired)
VEHICLE (Veh_vinnum, Veh_licplate#, Veh_msrp, Veh_model_yr, Veh_sls_fname, Veh_sls_minit, Veh_sls_lname)
# VEHICLE [Veh_sls_fname, Veh_sls_minit, Veh_sls_lname] ⊆ SALESPERSON [Sls_fname, Sls_minit, Sls_lname] or Ø
24. List (tabulate) the metadata available in the ER diagram in Exercise 23 on the next page (see
page 301) and indicate the ones captured in the logical (relational) schema of design 23(a)
and design 23(b).
Answer. The metadata available in the ER diagram in Exercise 23 includes the type and size
of each attribute, whether the attribute is mandatory or optional, and whether the attribute is
a simple or composite specification of all uniqueness constraints, participation constraints,
and cardinality ratio constraints. On the other hand, considerable metadata is lost when
mapping the ER diagram to either of the logical schemas. Metadata lost includes the type
and size of each attribute, whether the attribute is mandatory or optional, all composite
attributes, all alternate keys (e.g., Lic_plate#), the nature of the cardinality ratio, and in the
case of the foreign key design using directed arcs, the nature of the participation constraints.
In the case of the foreign key design using inclusion dependencies, the optional or total
participation of the child is shown.
25. For the ER diagram in Exercise 23, specify the logical (relational) schema as per the cross
referencing design:
From the answer to (b) given below, it is easy to draw the two directed arcs.

SALESPERSON (Sls_empno, Sls_fname, Sls_minit, Sls_lname, Sls_pctcommission, Sls-basesalary, Sls_gender, Sls_datehired)
VEHICLE (Veh_vinnum, Veh_licplate#, Veh_msrp, Veh_model_yr)
SELLS (Sel_sls_fname, Sel_sls_minit, Sel_sls_lname, Sel_veh_vinnum)
# SELLS [Sel_sls_fname, Sel_sls_minit, Sel_sls_lname] ⊆ SALESPERSON [Sls_fname, Sls_minit, Sls_lname]

# SELLS [Sel_veh_vinnum] ⊆ VEHICLE [Veh_vinnum]
Also, explain the merits and demerits of this cross-referencing design over the foreign key
design solution.
Answer. The cross-referencing design guarantees absence of null values that would
otherwise appear in the VEHICLE relation had the foreign key design been used and vehicles
not sold by a salesperson existed. Strict use of the cross-referencing design necessitates the
creation of a separate relation in situations where partial participation exists, thus
increasing the number of relations in the database.
26. Consider the following excerpt from an ERD:

Salary
Sys_name
Qualification Sys_id
Name
(x, 1) Resident_expert (y, Size

1)
PROGRAMMER SYSTEM
Gender
Date_hired
For the following three cases, specify the logical (relational) schema using either directed
arcs or in terms of inclusion dependencies according to the foreign key design, cross-
referencing design and mutual-referencing design:
a. when x = 0 and y = 1
b. when x = 0 and y = 0
c. when x = 1 and y = 1
In each case, offer a comparative discussion of the merits and demerits of the three design
options.
Answer.
Exercise 26 - Part a.
Foreign Key Design
PROGRAMMER (Pr_empno, Pr_name, Pr_gender, Pr_date_hired, Pr_qualification, Pr_salary)
SYSTEM (Sys_sys_id, Sys_sys_name, Sys_size, Sys_pr_name)
# SYSTEM [Sys_pr_name] ⊆ PROGRAMMER [Pr_name]
Cross-referencing Design
RESIDENT_EXPERT (Rex_pr_name, Rex_sys_sys_id) {Note primary key of RESIDENT_EXPERT}
SYSTEM (Sys_sys_id, Sys_sys_name, Sys_size)
# RESIDENT_EXPERT [Rex_pr_name] ⊆ PROGRAMMER [Pr_name]
# RESIDENT_EXPERT [Rex_sys_sys_id] ⊆ SYSTEM [Sys_sys_id]
Mutual-referencing Design
PROGRAMMER (Pr_empno, Pr_name, Pr_gender, Pr_date_hired, Pr_qualification, Pr_salary, Pr_sys_sys_id)
# PROGRAMMER [Pr_sys_sys_id] ⊆ SYSTEM [Sys_sys_id]
Exercise 26 - Part b
Foreign Key Design
# SYSTEM [Sys_pr_name] ⊆ PROGRAMMER [Pr_name] or ∅
Cross-referencing Design
RESIDENT_EXPERT (Rex_pr_name, Rex_sys_sys_id)
SYSTEM (Sys_sys_id, Sys_sys_name, Sys_size)
# RESIDENT_EXPERT [Rex_pr_name] ⊆ PROGRAMMER [Pr_name]

# RESIDENT_EXPERT [Rex_sys_sys_id] ⊆ SYSTEM [Sys_sys_id]
Exercise 26 - Part c
27. Consider the following excerpt from an ERD:
Salary
Qualification Gender Date_hired
Name
Emp_no
(x, 1)
NURSE
Supervisor (0, n) (1, 1) Supervisee
Supervises
Specify the logical (relational) schema (choosing a design without a need to use null values
to indicate partial participation) in the following ways:

NURSE (Nur_empno, Nur_name, Nur_qualification, Nur_salary, Nur_gender, Nur_date_hired, Nur_nur_empno)
# NURSE [Nur_nur_empno] ⊆ NURSE [Nur_empno]

28. How can the design requirement in Exercise 27 above be satisfied if the “Supervisee” part of
the relationship has the structural constraints (0, 1)? Again, show a design using both directed
arcs and in terms of inclusion dependencies.

NURSE (Nur_empno, Nur_name, Nur_qualification, Nur_salary, Nur_gender, Nur_date_hired)
SUPERVISOR (Sup_Nur_empno, Sup_nur_nur_empno)
# SUPERVISOR [Sup_nur_empno] ⊆ NURSE [Nur_empno]
# SUPERVISOR [Sup_nur_nur_empno] ⊆ NURSE [Nur_empno]
29. Specify the logical schema for the ER diagram shown in Exercise 23 using the information-
preserving grammar, and indicate the metadata present in the ER diagram (Exercise 24)
captured by this logical schema.
Answer.
∙ ∙ ∙ ∙
L1: SALESPERSON (Sls_empno , [Sls_fname, Sls_minit, Sls_lname], Sls_pctcommission, Sls-basesalary , Sls_gender , Sls_datehired )
(N,5) (A,20) (A,1) (A,20) (N,2) (N,6) (A,1) (Dt,8)
0 <---------------------L1--------------------- > n
∙ ∙ ∙ ∙
L2: VEHICLE (Veh_vinnum, Q[Veh_licplate# ], Veh_msrp , Veh_model_yr , Veh_make , [Veh_sls_fname, Veh_sls_minit, Veh_sls_lname])
(A,30) (A,7) (N,5.2) (N,4) (A,13) (A,20) (A,1) (A,20)
0 <----------------------R----------------------> 1
30. Specify the logical schema for the ER diagram shown in Exercise 27 using the information-
preserving grammar.
Answer.
0 <-----L1------n>
∙ ∙ ∙ ∙
L1: NURSE (Nur_empno, Nur_name , Nur_qualification, Nur_salary , Nur_gender , Nur_date_hired , Nur_nur_empno)
(N,5) (A,30) (A,1) (N,6) (A,1) (Dt,8) (N,5)
1 <------D------1>
Since attribute type and size are not provided in the ER diagram, those given are assumed values. Likewise, since every nurse must have a
supervisor, the Set Default deletion rule was assumed to apply should the supervisor of a nurse be deleted.
31. Consider the following ERD:

Date
Prescription
Med_name #
Med_cod
e ------------------
(0,n) (1,1)
MEDICATION Listed_i PRESCRIPTION_
n ORDER
List_price
Using the foreign key design, specify the logical schema for this diagram in the following
ways:
a. with a directed arc
b. in terms of an inclusion dependency
c. using the information-preserving grammar.

MEDICATION (Med_med_code, Med_med_name, Med_list_price)
PRESCRIPTION_ORDER (Pod_med_med_code, Pod_prescription#, Pod_date)
# PRESCRIPTION_ORDER [Pod_med_med_code] ⊆ MEDICATION [Med_med_code]
c. using the information-preserving grammar:

∙
L1: MEDICATION (Med_med_code, Q[Med_med_name ], Med_list_price)
(A,3) (A,30) (N,5.2)
0 <------L1-------n>
∙
L2: PRESCRIPTION_ORDER (Pod_med_med_code, Pod_prescription#, Pod_date )
(A,3) (X,10) (Dt,8)
1 <-------R--------1>
32. Consider the following Presentation-Layer ERD:

Name Size Name Major
Headquarters
Status
Year Quarter
COMPANY
STUDENT
Location Period
Stipend
1 1
INTERNSHIP n
m
Provides Gets
Using the foreign key design, specify the logical schema in the following ways:
a) with directed arcs

b) in terms of inclusion dependencies
c) using the information-preserving grammar.
Also, list the metadata present in the ER diagram and indicate the ones captured by each of
the three designs of the logical schema.

COMPANY (Cmp_name, Cmp_size, Cmp_headquarters)
STUDENT (Stu_name, Stu_major, Stu_status)
INTERNSHIP (Int_cmp_name, Int_stu_name, Int_location, Int_stipend, Int_year, Int_quarter)
# INTERNSHIP [Int_cmp_name] ⊆ COMPANY [Cmp_name]
# INTERNSHIP [Int_stu_name] ⊆ STUDENT [Stu_name]
c. using the information-preserving grammar:
L1: COMPANY (Cmp_name, Cmp_size, Cmp_headquarters)

(A,30) (N,6) (A,30)
L2: STUDENT (Stu_name, Stu_major, Stu_status)

(A,30) (A,20) (A,10)
1<--L1---m> 0---L2---n>
L3: INTERNSHIP (Int_cmp_name, Int_stu_name, Int_location, Int_stipend, [Int_year, Int_quarter])
(A,30) (A,30) (A,20) (N,5) (N,4) (A,2)
1<--C---1> 0----C----1>
33. Specify the logical (relational) schema for the ER diagram shown in Figure 5-61 in Chapter 5
for the Cougar Medical Associates as per the foreign key design:
Answer.
The very purpose this question is to demonstrate how impractical it is to use the directed
arc technique for specifying the logical schema for a real-world type of a large ER model.
PERSON (Per_ssno, Per_name, Per_gender, Per_address, Per_phone)

CLINIC_PERSONNEL (Clp_per_ssno, Clp_emp#)
CLINIC_PERSONNEL {Clp_per_ssno} ⊆ PERSON {Per_ssno}
NURSE (Nur_clp_emp#, Nur_salary, Nur_grade, Nur_yrs_experience)

NURSE {Nur.clp_emp#} ⊆ CLINIC_PERSONNEL {Clp_emp#}
SURGEON (Sur_clp_emp#, Sur_speciality, Sur_con_type, Sur_con_years)
SURGEON {Sur_clp_emp#} ⊆ CLINIC_PERSONNEL {Clp_emp#}
PHYSICIAN (Phy_clp_emp#, Phy_speciality, Phy_salary)
PHYSICIAN {Phy_clp_emp#} ⊆ CLINIC_PERSONNEL {Clp_emp#}
MEDICAL_CORPORATION (Mco_corp_name, Mco_headquarters)
CLINIC_OWNER (Clo_owner#, Clo_phy_clp_emp#, Clo_percent_own, Clo_mco_corp_name)
SUPPORT_STAFF (Sst_clp_per_ssno, Sst_salary)
SUPPORT_STAFF {Sst_clp_per_ssno} ⊆ CLINIC_PERSONNEL {Clp_emp#}
SURGERY_SKILL (Ssk_skill_code, Ssk_description)
NURSE_SKILL (Nsk_nur_clp_emp#, Nsk_ssk_skill_code)
NURSE_SKILL {Nsk_nur_clp_emp#} ⊆ NURSE {Nur_clp_emp#}
NURSE_SKILL {Nsk_ssk_skill_code} ⊆ SURGERY_SKILL {Ssk_skill_code}
SURGERY_TYPE (Stp_s_code, Stp_name, Stp_special_needs, Stp_category, Stp_anat_location)
ASSIGNMENT (Asg_nur_clp_emp#, Asg_stp_s_code, Asg_nsk_nur_clp_emp#, Asg_nsk_ssk_skill_code,
Asg_req_stp_s_code, Asg_req_ssk_skill_code)
ASSIGNMENT {Asg_nur_clp_emp#} ⊆ NURSE {Nur_clp_emp#}
ASSIGNMENT {Asg_stp_s_code} ⊆ SURGERY_TYPE {Stp_s_code}
ASSIGNMENT {Asg_nsk_nur_clp_emp#, Asg_nsk_ssk_skill_code} ⊆ NURSE_SKILL
{Nsk_nur_clp_emp#, Nsk_ssk_skill_code}
ASSIGNMENT {Asg_req_stp_s_code, Asg_req_ssk_skill_code} ⊆ REQ_SKILL {Req_stp_s_code,
Req_ssk_skill_code}
PATIENT (Pat_per_ssno)
IN_PATIENT (Inp_pat_per_ssno, Inp_admit_date, Inp_nursing_unit, Inp_bed#, Inp_room#, Inp_wing,
Inp_nur_clp_emp#)
IN_PATIENT {Inp_pat_per_ssno} ⊆ PATIENT {Pat_per_ssno}
IN_PATIENT {Inp_nur_clp_emp#} ⊆ NURSE {Nur_clp_emp#}
PERSONAL_INFO (Pif_pat_per_ssno, Pif_Patient#, Pif_birthdate)
PERSONAL_INFO {Pif_pat_per_ssno} ⊆ PATIENT {Pat_per_ssno}
MEDICAL_INFO (Mif_pat_per_ssno, Mif_blood_sugar, Mif_blood_type, Mif_heart_risk, Mif_hdl, Mif_ldl,
Mif_triglyceride)
MEDICAL_INFO {Mif_pat_per_ssno} ⊆ PATIENT {Pat_per_ssno}
ALLERGY (All_mif_pat_per_ssno, All_code, All_description)
ALLERGY {All_mif_pat_per_ssno} ⊆ MEDICAL_INFO {Mif_pat_per_ssno}
ILLNESS (Ill_code, Ill_description)

SUFFERING (Suf_pat_per_ssno, Suf_ill_code)
SUFFERING {Suf_pat_per_ssno} ⊆ PATIENT {Pat_per_ssno}
SUFFERING {Suf_ill_code} ⊆ ILLNESS {Ill_code}
MEDICATION (Med_Med_code, Med_name, Med_ytd_usage, Med_q_on_order, Med_q_on_hand,
Med_unit_cost)
INTERACTION (Int_med_med_code_sourceof, Int_med_med_code_subjectto)
INTERACTION {Int_med_med_code_sourceof} ⊆ MEDICATION {Med_med_code}
INTERACTION {Int_med_med_code_subjectto} ⊆ MEDICATION {Med_med_code}
PRESCRIPTION (Pre_phy_clp_emp#, Pre_pat_per_ssno, Pre_med_med_code, Pre_frequency, Pre_dosage)
PRESCRIPTION {Pre_phy_clp_emp#} ⊆ PHYSICIAN {Phy_clp_emp#}
PRESCRIPTION {Pre_pat_per_ssno} ⊆ PATIENT {Pat_per_ssno}
PRESCRIPTION {Pre_med_med_code} ⊆ MEDICATION {Med_med_code}
MED_TAKEN (Met_pat_per_ssno, Med_pre_phy_clp_emp#, Med_pre_pat_per_ssno, Med_pre_med_med_code,
Met_med_med_code)
MED_TAKEN {Met_pat_per_ssno} ⊆ PATIENT {Pat_per_ssno}
MED_TAKEN (Met_med_med_code} ⊆ MEDICATION {Med_med_code}
MED_TAKEN {Med_pre_phy_clp_emp#, Med_pre_pat_per_ssno, Med_pre_med_med_code} ⊆ PRESCRIPTION
{Pre_phy_clp_emp#, Pre_pat_per_ssno, Pre_med_med_code}
SURG_SCH (Sch_pat_per_ssno, Sch_stp_s_code, Sch_sur_clp_emp#, Sch_surg_date, Sur_theatres)
SURG_SCH {Sch_pat_per_ssno} ⊆ PATIENT {Pat_per_ssno}
SURG_SCH {Sch_stp_s_code} ⊆ SURGERY_TYPE {Stp_s_code}
SURG_SCH {Sch_sur_clp_emp#} ⊆ SURGEON {Sur_clp_emp#}
REQ_SKILL (Req_stp_s_code, Req_ssk_skill_code)
REQ_SKILL {Req_stp_s_code} ⊆ SURGERY_TYPE {Stp_s_code}
REQ_SKILL {Req_ssk_skill_code} ⊆ SURGERY_SKILL {Ssk_skill_code}
The miscellaneous business rule:

• a surgery type must have at least two nurses assigned to it
must be carried forward as a semantic integrity constraint to physical database design.

Data Modeling and Database Design 2nd Edition Umanath Solutions Manual 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Data Modeling and Database Design 2nd Edition Umanath Solutions Manual 1

Uploaded by

Copyright:

Available Formats

Data Modeling and Database Design 6-1

Data Modeling and Database Design 2nd Edition Umanath

Chapter 6 – The Relational Data Model

Chapter 6 Key Terms

Relational algebra A series of data manipulation operations

Candidate key A superkey with no proper subsets that are

Union operation A relational algebra operation that adds the

Cross-referencing design A logical data modeling approach used to

1. Define the terms, tuple, attribute, and relation.

4. What is a null value? What gives rise to null values in a relation?

5. Distinguish between a subset and a proper subset?

Student Student Student Class Class

10b. The difference of R1 and R2

10c. The difference of R2 and R1

10d. The intersection of R1 and R2

DRIVER (Dr_license_no, Dr_name, Dr_city, Dr_state)

Tic_Ticket_no Tic_ticket_date Tic_dr_license_no Tic_ttp_offense

13. Discuss the concept of information preservation in data model mapping.

17. What is the purpose of the cross-referencing design?

18. What complicates the mapping of 1:1 cardinality ratios?

19. Describe mutual referencing and the complexities that it introduces.

20. What information is lost by the use of the information-reducing grammar?

a. Directed arc method:

b. inclusion dependencies technique:

VEHICLE (Veh_vinnum, Veh_licplate#, Veh_msrp, Veh_model_yr, Veh_sls_fname, Veh_sls_minit, Veh_sls_lname)

# VEHICLE [Veh_sls_fname, Veh_sls_minit, Veh_sls_lname] ⊆ SALESPERSON [Sls_fname, Sls_minit, Sls_lname] or Ø

a. Directed arc method:

b. inclusion dependencies technique:

VEHICLE (Veh_vinnum, Veh_licplate#, Veh_msrp, Veh_model_yr)

SELLS (Sel_sls_fname, Sel_sls_minit, Sel_sls_lname, Sel_veh_vinnum)

# SELLS [Sel_sls_fname, Sel_sls_minit, Sel_sls_lname] ⊆ SALESPERSON [Sls_fname, Sls_minit, Sls_lname]

26. Consider the following excerpt from an ERD:

(x, 1) Resident_expert (y, Size

PROGRAMMER (Pr_empno, Pr_name, Pr_gender, Pr_date_hired, Pr_qualification, Pr_salary)

SYSTEM (Sys_sys_id, Sys_sys_name, Sys_size, Sys_pr_name)

# SYSTEM [Sys_pr_name] ⊆ PROGRAMMER [Pr_name]

PROGRAMMER (Pr_empno, Pr_name, Pr_gender, Pr_date_hired, Pr_qualification, Pr_salary)

RESIDENT_EXPERT (Rex_pr_name, Rex_sys_sys_id) {Note primary key of RESIDENT_EXPERT}

SYSTEM (Sys_sys_id, Sys_sys_name, Sys_size)

# RESIDENT_EXPERT [Rex_pr_name] ⊆ PROGRAMMER [Pr_name]

# RESIDENT_EXPERT [Rex_sys_sys_id] ⊆ SYSTEM [Sys_sys_id]

SYSTEM (Sys_sys_id, Sys_sys_name, Sys_size, Sys_pr_name)

# SYSTEM [Sys_pr_name] ⊆ PROGRAMMER [Pr_name]

# PROGRAMMER [Pr_sys_sys_id] ⊆ SYSTEM [Sys_sys_id]

PROGRAMMER (Pr_empno, Pr_name, Pr_gender, Pr_date_hired, Pr_qualification, Pr_salary)

SYSTEM (Sys_sys_id, Sys_sys_name, Sys_size, Sys_pr_name)

# SYSTEM [Sys_pr_name] ⊆ PROGRAMMER [Pr_name] or ∅

PROGRAMMER (Pr_empno, Pr_name, Pr_gender, Pr_date_hired, Pr_qualification, Pr_salary)

RESIDENT_EXPERT (Rex_pr_name, Rex_sys_sys_id)

SYSTEM (Sys_sys_id, Sys_sys_name, Sys_size)

# RESIDENT_EXPERT [Rex_pr_name] ⊆ PROGRAMMER [Pr_name]

# RESIDENT_EXPERT [Rex_sys_sys_id] ⊆ SYSTEM [Sys_sys_id]

PROGRAMMER (Pr_empno, Pr_name, Pr_gender, Pr_date_hired, Pr_qualification, Pr_salary, Pr_sys_sys_id)

SYSTEM (Sys_sys_id, Sys_sys_name, Sys_size, Sys_pr_name)

# SYSTEM [Sys_pr_name] ⊆ PROGRAMMER [Pr_name]

# PROGRAMMER [Pr_sys_sys_id] ⊆ SYSTEM [Sys_sys_id]

SYSTEM (Sys_sys_id, Sys_sys_name, Sys_size, Sys_pr_name)

# SYSTEM [Sys_pr_name] ⊆ PROGRAMMER [Pr_name]

# PROGRAMMER [Pr_sys_sys_id] ⊆ SYSTEM [Sys_sys_id]

27. Consider the following excerpt from an ERD:

Supervisor (0, n) (1, 1) Supervisee

a. Directed arc method:

b. inclusion dependencies technique:

# NURSE [Nur_nur_empno] ⊆ NURSE [Nur_empno]