a) Given the following entity relationship diagram:
(i)
write the proper cardinalities for (a,b), (c,d), (e,f ),
(g,h), (i,j), (k,l), (m,n) and
(o,p). Explain your answer and list all assumptions.
(ii)
write the proper connectivity for: W, X, Y and Z and
explain the answer.
W
X
STORE
Z
ORDER
(e,f)
(a,b)
Y
(g,h)
PRODUCT
(i,j)
(k,l)
employs
(c,d)
claims
EMPLOYEE
(m,n)
DEPENDENT
(o,p)
Business Rules:
1. There can be many employees working in a store but an
employee can only work in one store. It is also true that there
could be occasions whereby a store has currently no employees.
2. There can be many orders created for a store but an order can
only be associated to one store. It is also true that there could be
occasions whereby a store has currently no orders.
3. There can be many orders created for a product but an order
can only be associated with one product. It is also true that there
could be occasions whereby a product is not associated with any
orders.
4. An employee can have many dependants but a dependant can
only be associated to one employee. It is also true that there
could be occasions whereby an employee has no dependants.
Symbol Cardinality Rationale
(a,b)
(0,N)
A store may employ many employees,
but does not have to employ any.
(c,d)
(1,1)
An employee must be assigned to a
store.
(e,f)
(0,N)
A store may place many orders, but
does not have to place any.
(g,h)
(1,1)
An order must be placed by a store.
An order can only come from one
store.
(i,j)
(1,1)
An order must specify a product, and
each order may only specify a single
product.
(k,l)
(0,N)
A product may appear on many orders,
but does not have to appear on any.
(m,n)
(0,N)
An employee may not have any
dependants, but they could have
several
(o,p)
(1,1)
If a dependant is not associated with
an employee, then they are not a
dependant
Page 171, Question 21
Connectivities for:
W
1
X
M
Y
Z
M
1
Create an ERD based on the Crow’s Foot model, using the
following requirements.



An INVOICE is written by a SALESREP. Each sales representative can
write many invoices, but each invoice is written by a single sales
representative.
The INVOICE is written for a single CUSTOMER. However, each
customer may have many invoices.
An INVOICE may include many detail lines (LINE), which describe the
products bought by the customer.


The product information is stored in a PRODUCT entity.
The product's vendor information is found in a VENDOR entity.
Figure P4.8a The Crow’s Foot ERD for Problem 8
Figure P4.8b The Chen ERD for Problem 8
CUSTOMER
(0,N)
1
generates
EMPLOYEE
1
(0,N)
M
(1,1)
M
writes
1
VENDOR
INVOICE
(1,1)
1
(1,N)
(0,N)
contains
M
(1,1)
delivers
M
1
is written in
INV_LINE
(1,1)
(1,1)
PRODUCT
(0,N)
1. Given the dependency diagram shown below answer the
following Questions
C1
C2
C3
C4
C5
a. Create a database whose tables are at least in 2NF, showing the
dependency diagrams for each table.
M
Table 1
C1
Primary key: C1
Foreign key: None
Normal form: 3NF
C2
Table 2
C1
C3
C4
C5
Primary key: C1 + C3
Foreign key: C1 (to Table 1)
Normal form: 2NF, because the
table exhibits the transitive
dependencies C4
C5
b. Create a database whose tables are at least in 3NF, showing the
dependency diagrams for each table.
C1
C1
C3
C4
C2
Table 1
Primary key: C1
Foreign key: None
Normal form: 3NF
C4
Table 2
Primary key: C1 + C3
Foreign key: C1 (to Table 1)
C4 (to Table 3)
Normal form: 3NF
C5
Table 3
Primary key: C4
Foreign key: None
Normal form: 3NF
2. This is similar to ORD_Line only the PROD_NUM is
used in the primary key rather than the somewhat
artificial attribute, LINE_NUM.
INV_ PROD
NUM _NUM
SALE
_DAT
E
PROD
_DES
C
VEND
_COD
E
VEND
_NAM
E
NUM_
SOLD
PROD
_PRIC
E
3.
INV_NU
M
PROD_NU
M
SALE_DAT
E
VEND_COD
E
2NF
VEND_CODE VEND_NAME
3NF
PROD_NUM PROD_DESC PROD_PRICE
3NF
NUM_SOL
D
4. To keep track of office furniture, computers, printers, and so on,
the FOUNDIT company uses the table structure shown in Table
below:
Table
Attribute Name
Sample Value Sample
Value
ITEM_ID
231134-678
342245-225
ITEM_LABEL
HP
DeskJet HP Toner
895Cse
ROOM_NUMBER 325
325
BLDG_CODE
NTC
NTC
BLDG_NAME
Nottooclear
Nottoclear
BLDG_MANAGER I. B. Rightonit I.
B.
Rightonit
Sample
Value
254668-449
DT Scanner
123
CSF
Canseefar
May B. Next
Given this information, draw the dependency diagram. Make
sure you label the transitive and/or partial dependencies.
The answer to this problem is shown in combination with Problem 9's
answer to show the decomposition process.
5. Starting with the dependency diagram drawn for Problem 4,
create a set of dependency diagrams that meet 3NF requirements.
Rename attributes to meet the naming conventions, and create new
entities and attributes as necessary.
The dependency diagrams in Figure P5.8&9 reflect the notion that one
employee manages each building.
As you discuss the dependency diagrams in Figure P4.8&9, remind
the students that BLDG_CODE is not a determinant of
BLDG_ROOM. A building can have many rooms, so knowing the
building code will not tell you what the room in that building is.
If the room is numbered to reflect the building it is in – for example,
HE105 indicates room 105 in the Heinz building – one might argue
that the BLDG_ROOM value is the determinant of the BLDG_CODE
and the BLDG_NAME values. (You will learn in Chapter 5 that you
can create a query to find a building by looking at room prefixes.)
However, if you define dependencies in strictly relational algebra
terms, you might argue that partitioning the attribute value to “create”
a dependency indicates that the partitioned attribute is not (in that
strict sense) a determinant. Although we have indicated a transitive
dependency from BLDG_ROOM to BLDG_CODE and
BLDG_NAME, we have used a dotted line to indicate that there is
room for argument in this set of transitive dependencies. In any case,
the (arguable) dependency BLDG_ROOM  BLDG_CODE does not
create any problems in a practical sense, so we have not identified it in
the Problem 9 solution.
Clearly, BLDG_CODE is a determinant of BLDG_NAME. Therefore,
the transitive dependency is marked properly in the Problem 8
solution.
Figure P5.8&9 The Dependency Diagrams for Problems 4 and 5
Problem 8 Solution
ITEM_ID ITEM_DESCRIPTION BLDG_ROOM BLDG_CODE BLDG_NAME BLDG_MANAGER
Transitive Dependencies (See discussion in the IM text).
Problem 9 Solution: All tables in 3NF
ITEM_ID ITEM_DESCRIPTION BLDG_ROOM BLDG_CODE
BLDG_CODE BLDG_NAME
EMP_CODE
EMP_CODE
EMP_LNAME EMP_FNAME
EMP_INITIAL
6. Using the results of Problem 5, draw the Crow’s Foot ERD.
Use Figure P5.10 to show that, in this case, the ER diagram reflects
the business rule that one employee can manage many (or at least
more than one) building. Because all employees are not required to
manage buildings, BUILDING is optional to EMPLOYEE in the
manages relationship. Once again, the nature of this relationship is not
and cannot be reflected in the dependency diagram.
Figure P5.10a The Crow’s Foot ERD for Problem 10
As you examine Figure P5.10a, note that the BLDG_ROOM is
actually an ITEM entity attribute, so it is appropriate to rename it
ITEM_ROOM. Also, keep in mind that a room may be related to the
building in which it is located. (A BUILDING may contain many
ROOMs. Each ROOM is located in a single building.) Therefore, you
can expand the design shown in Figure P5.10a to the one shown in
Figure P5.10b. This solution assumes that a room is directly traceable
to a building. For example, room SC-508 would be located in the
Science (SC) Building and room BA-305 would be located in the
Business Administration (BA) building. Note that we have made
ROOM optional to BUILDING to reflect the likelihood that some
buildings – such as storage sheds -- may not contain designated
(numbered) rooms. Although optionalities make excellent default
conditions, it is always wise to establish the optionality based on a
business rule. In any case, the designer must ask about the nature of
the room/building relationship.
Figure P5.10b The Expanded Crow’s Foot ERD for Problem 10
7. Assume that we have a set of attributes {A, B, C, D, E, F,
G} and the functional dependencies:
BCD  A, BC  E, A  F, F  G, C  D, A  G
Factor this set of attributes into relations that are in 3NF. Are all of your
tables in BCNF? Why or why not.
1NF
A
B
C
D
E
F
G
2NF/3NF
B
C
D
A
3NF
2NF
A
F
A
F
G
3NF
F
G
2NF/3NF
B
C
E
2NF/3NF
C
D
The dependencies in the final 3NF tables are (one line per table):
BCD  A
AF
FG
BC  E
CD
All the 3NF tables are in BCNF because all the non-key values are
dependent on the key, the whole key and nothing but the key.