Week 4&5 Assignment Solution

1. Use the following business rules to create a Crows Foot ERD. Write all
appropriate connectivities and cardinalities in the ERD.
a. A department employs many employees, but each employee is
employed by one department.
b. Some employees, known as rovers, are not assigned to any
department.
c. A division operates many departments, but each department is
operated by one division.
d. An employee may be assigned many projects, and a project may
have many employees assigned to it.
e. A project must have at least one employee assigned to it.
f. One of the employees manages each department, and each
department is managed by only one employee.
g. One of the employees runs each division, and each division is run by
only one employee.

ERD Solution

As you discuss the ERD, note that this design reflects several useful features
that become especially important when the design is implemented. For
example:

The ASSIGN entity is shown to be optional to the PROJECT. This decision

makes sense from a practical perspective, because it lets you create a
new project record without having to create a new assignment record. (If
a new project is started, there will not yet be any assignments.)
The relationship expressed by DEPARTMENT employs EMPLOYEE is
shown as mandatory on the EMPLOYEE side. This means that a
DEPARTMENT must have at least one EMPLOYEE in order to have
departmental status. However, DEPARTMENT is optional to EMPLOYEE, so
an employee can be entered without entering a departmental FK value. If
the existence of nulls is not acceptable, you can create a No
assignment record in the DEPARTMENT table, to be referenced in the
EMPLOYEE table if an employee is not assigned to a department.
Note also the implications of the 1:1 EMPLOYEE manages DEPARTMENT
relationship. The flip side of this relationship is that each DEPARTMENT is
managed by one EMPLOYEE. (This latter relationship is shown as
mandatory in the ERD. That is, each department must be managed by an
employee!) Therefore, one of the EMPLOYEE tables PK values must
appear as the FK value in the DEPARTMENT table. (Because this is a
1:1 relationship, the index property of the EMP_NUM FK in the
DEPARTMENT table must be set to unique.)
Although you ought to approach a 1:1 relationship with caution most
1:1 relationships are the result of a misidentification of attributes as
entities the 1:1 relationships reflected in the EMPLOYEE manages
DEPARTMENT and EMPLOYEE runs DISISION are appropriate. These 1:1
relationships avoid the data redundancies you would encounter if you
duplicated employee data such a names, phones, and e-mail addresses
in the DIVISION and DEPARTMENT entities.

Also, if you have multiple relationships between two entities -- such as the
EMPLOYEE manages DEPARTMENT and DEPARTMENT employs EMPLOYEE
relationships you must make sure that each relationship has a designated
primary entity. For example, the 1:1 relationship expressed by EMPLOYEE
manages DEPARTMENT requires that the EMPOYEE entity be designated as the
primary (or first) entity. If you use Visio to create your Crows Foot ERDs, Figure
P4.3 show how the 1:1 relationship is specified. If you use some other CASE tool,
you will discover that it, too, is likely to require similar relationship specifications.

3. United Helpers is a nonprofit organization that provides aid to people after natural
disasters. Based on the following brief description of operations, create the appropriate
fully labeled Crows Foot ERD.

Individuals volunteer their time to carry out the tasks of the organization. For each
volunteer, their name, address, and telephone number are tracked. Each volunteer
may be assigned to several tasks during the time that they are doing volunteer work,
and some tasks require many volunteers. It is possible for a volunteer to be in the

system without having been assigned a task yet. It is possible to have tasks that no
one has been assigned. When a volunteer is assigned to a task, the system should
track the start time and end time of that assignment.

For each task, there is a task code, task description, task type, and a task status. For
example, there may be a task with task code 101, description of answer the
telephone, a type of recurring, and a status of ongoing. There could be
another task with a code of 102, description of prepare 5000 packages of basic
medical supplies, a type of packing, and a status of open.

For all tasks of type packing, there is a packing list that specifies the contents of
the packages. There are many different packing lists to produce different packages,
such as basic medical packages, child care packages, food packages, etc. Each
packing list has a packing list ID number, packing list name, and a packing list
description, which describes the items that ideally go into making that type of
package. Every packing task is associated with only one packing list. A packing list
may not be associated with any tasks, or may be associated with many tasks. Tasks
that are not packing tasks are not associated with any packing list.

Packing tasks result in the creation of packages. Each individual package of

supplies that is produced by the organization is tracked. Each package is assigned
an ID number. The date the package was created, and total weight of the package is
recorded. A given package is associated with only one task. Some tasks (e.g.,
answer the phones) will not have produced any packages, while other tasks (e.g.,
prepare 5000 packages of basic medical supplies) will be associated with many
packages.

The packing list describes the ideal contents of each package, but it is not always
possible to include the ideal number of each item. Therefore, the actual items
included in each package should be tracked. A package can contain many different
items, and a given item can be used in many different packages.

For each item that the organization provides, there is an item ID number, item
description, item value, and item quantity on hand stored in the system. Along with
tracking the actual items that are placed in each package, the quantity of each item
placed in the package must be tracked too. For example, a packing list may state
that basic medical packages should include 100 bandages, 4 bottles of iodine, and 4
bottles of hydrogen peroxide. However, because of the limited supply of items, a
given package may include only 10 bandages, 1 bottle of iodine, and no hydrogen
peroxide. The fact that this package includes bandages and iodine needs to be
recorded along with the quantity of each that is included. It is possible for the
organization to have items donated that have not been included in any package yet,
but every package will contain at least one item.

United Helpers ERD

This problem, however, does leave room for interesting discussion with the students
regarding the need to verify requirements with the business users. In fact, getting
unambiguous business rules can be one of the most difficult parts of the design process. In
this problem, the potential for a relationship between the packing list (LIST) and the items
(ITEM) stocked by the organization can be a source for discussion. Students may envision
that a LIST can specify many ITEMs and an ITEM can be specified in many LISTs. This
would imply the need for a M:N relationship between ITEM and LIST. However, the
business users may not intend for the packing list to be that specific. For example, the
packing list may specify that "2 liter of iodine" should be included in a given type of package
without specifying whether it should be two 1-liter bottles of iodine or four 500ml bottles of
iodine. Note that "1-liter bottle of iodine" and "500ml bottle of iodine" would have to be
separate entity instances in ITEM because they have different values. If it is the case that the

packing list is intentionally generic in its description of the ideal contents, then a relationship
between LIST and ITEM would not be appropriate.