1. Use the following business rules to create a Crow’s Foot ERD. Write all appropriate connectivities and
cardinalities in the ERD.
a. A department employs many employees, but each employee is employed by only 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 only 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.
the ERD shown in Figure note that this design reflects several useful features that become especially
important when the design is implemented.
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 table’s 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 Crow’s Foot ERDs, Figure 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.
2. The Jonesburgh County Basketball Conference (JCBC) is an amateur basketball association. Each city in
the county has one team as its representative. Each team has a maximum of 12 players and a minimum
of 9 players. Each team also has up to three coaches (offensive, defensive, and physical training
coaches). During the season, each team plays two games (home and visitor) against each of the other
teams. Given those conditions, do the following:
a. Identify the connectivity of each relationship.
b. Identify the type of dependency that exists between CITY and TEAM.
c. Identify the cardinality between teams and players and between teams and city.
d. Identify the dependency between coach and team and between team and player.
e. Draw the Chen and Crow’s Foot ERDs to represent the JCBC database.
f. Draw the UML class diagram to depict the JCBC database.
Each team plays ea
Each team plays at least twice: once as the home team and once as the visiting team.
Given these relationships, it becomes clear that TEAM participates in a recursive M:N relationship with
GAME. The relationship between TEAM and GAME becomes clearer if we list some attributes for
each of these entities. Note that the TEAM_NUM appears twice in a GAME record: once as a
GAME_HOME_TEAM and once as a GAME_VISIT_TEAM.
The relational diagram depicted in Figure is the result of implementing this method. (Note that if you
use Microsoft Access to execute this design, Access will create a virtual table named TEAM 1 to indicate
that there are two links between GAME and TEAM.) We constructed a database called Ch04 JCBC V1 to
demonstrate this design implementation.
Figure Chen's method produces a database that allows users to keep track of all games. A simple query
based on the two relationships between TEAM and GAME, for example, produces the result displayed in
Figure. (Only a few records have been generated to reflect the results of games 1 and 2 between teams
named Bears, Rattlers, Sharks, and Tigers, respectively.)
Check the relational diagram in Figure as you evaluate the design and its implementation. Because the
TEAM NUM appears twice in GAME: once as the GAME HOME TEAM and once as the GAME VISIT TEAM,
this approach employs synonyms. Because of the use of these synonyms, the GAME entity becomes
structurally quite complicated when you decide to track more game data. If you wanted to keep track of
runs, hits, and errors, for example, you'd need one set of each for each of the two teams in the same
record. Clearly, such a structure is undesirable: using synonyms necessitates the creation of two new
qualities, one for the home and the other for the workplace and one for the visiting team for each
additional characteristic you want to track.
3. Create an ERD based on the Crow’s Foot notation, using the following requirements:
a. An INVOICE is written by a SALESREP. Each sales representative can write many invoices, but each
invoice
is written by a single sales representative.
b. The INVOICE is written for a single CUSTOMER. However, each customer can have many invoices.
c. An INVOICE can include many detail lines (LINE), each of which describes one product bought by the
customer.
d. The product information is stored in a PRODUCT entity.
e. The product’s vendor information is found in a VENDOR entity.
4. The Hudson Engineering Group (HEG) has contacted you to create a conceptual model whose
application will meet the expected database requirements for the company’s training program. The HEG
administrator gives you the description (see below) of the training group’s operating environment.
(Hint: Some of the following sentences identify the volume of data rather than cardinalities. Can you tell
which ones?) The HEG has 12 instructors and can handle up to 30 trainees per class. HEG offers five
Advanced Technology courses, each of which may generate several classes. If a class has fewer than 10
trainees, it will be canceled. Therefore, it is possible for a course not to generate any classes. Each class
is taught by one instructor. Each instructor may teach up to two classes or may be assigned to do
research only. Each trainee may take up to two classes per year. Given that information, do the
following:
a. Define all of the entities and relationships. (Use Table 4.4 as your guide.)
During each training period, a COURSE does not necessarily generate a class. (Because certain courses
are offered every other period or during other time periods, it is plausible to infer that CLASS is not
required for COURSE.)
A COURSE must be associated with each CLASS. (The class must cover the specified course topic!) As a
result, COURSE is required for CLASS.
Some professors may only give a class every other period or even once in a while. As a result, it's safe to
presume that INSTRUCTOR can opt out of CLASS at any time during the enrolment period. This flexibility
makes sense from an implementation standpoint as well. If you hire a fresh instructor, for example, he
or she will have never taught a class before.
During some time period, not all trainees are likely to be enrolled in lessons. In fact, many trainees are
likely to receive informal "on the job" training rather than attending official lectures in the actual world.
As a result, it's safe to believe that ENROLL is a choice for TRAINEE.
Without a trainee, you can't establish an enrollment record. As a result, TRAINEE is required to ENROLL.
(As an aside, why not make TRAINEE an optional relationship to ENROLL? Optional relationships can be
utilized for operational reasons whether or not they are derived directly from a business rule.)
b. Describe the relationship between instructor and class in terms of connectivity, cardinality, and
existence dependence.
A trainee can enroll in multiple classes, and each class has a large number of students (10 or more),
resulting in a M:N relationship between TRAINEE and CLASS. (As a result, a composite entity serves as a
link between TRAINEE and CLASS.)
Only one instructor can teach a class, although an instructor can teach up to two classes. As a result,
INSTRUCTOR and CLASS have a 1:M connection.
A COURSE may not create any CLASSES if an insufficient amount of individuals sign up for it, but each
CLASS must represent a COURSE.
By supplying sample characteristics for each of the entities, you can add a lot of detail to the ERD. You
can also have your student declare the nature – weak or strong – of the relationships between the
entities using Visio Professional. Last but not least, tell your pupils that the order in which the properties
occur in each object is irrelevant. As a result, the (compound) PK of the can be expressed as CLASS CODE
+ TRN NUM or TRN NUM + CLASS CODE. As a result, it makes no difference whether one of the foreign
key properties is FK1 or FK2.
Note that the essential components of this problem can be found in the text's Figure as you explore the
ERD illustrated in Figure. It's also worth noting that the ENROLL entity in Figure employs a composite PK
(TRN NUM + CLASS CODE), implying that the ENROLL, CLASS, and TRAINEE links are strong. Finally,
explain why there is a weak link between COURSE and CLASS: the PK (CLASS CODE) of the CLASS entity
does not "borrow" the PK of the parent COURSE object. The link between COURSE and CLASS would
have been strong if the PK of the CLASS object had been CRS CODE + CLASS SECTION.
The purpose of the book is to demonstrate the two possible strengths of the link between COURSE and
CLASS. Emphasize that the PK component(s) chosen is usually a designer decision, but that singleattribute PKs give more design alternatives than composite PKs. Even the composite ENROLL object can
be changed to have a single-attribute PK, like ENROLL NUM. Given that option, CLASS CODE + TRN NUM
form a candidate key; CLASS CODE and TRN NUM remain foreign keys to CLASS and TRAINEE,
respectively. To avoid multiple enrollments in the latter circumstance, you can establish a (unique)
composite index.