Developing an ER Diagram: A Step-by-Step Guide for Database Design, Lecture notes of Database Management Systems (DBMS)

Development Of an Entity Relationship Diagram

Typology: Lecture notes

2017/2018

Uploaded on 04/13/2018

jeremy-kabaya
jeremy-kabaya 🇰🇪

5

(1)

4 documents

1 / 3

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
DEVELOPING AN ER DIAGRAM
The process of database design is an iterative rather than a linear or
sequential process. The verb iterates means “to do again or
repeatedly.” An iterative process is, thus, one based on repetition of
processes and procedures.
Building an ERD usually involves the following activities:
_ Create a detailed narrative of the organization’s description of
operations.
_ Identify the business rules based on the description of operations.
_ Identify the main entities and relationships from the business rules.
_ Develop the initial ERD.
_ Identify the attributes and primary keys that adequately describe the
entities.
_ Revise and review the ERD.
To illustrate the use of the iterative process that ultimately yields a
workable ERD, let’s start with an initial interview with the Tiny College
administrators. The interview process yields the following business
rules:
1. Tiny College (TC) is divided into several schools: a school of
business, a school of arts and sciences, a school of education,
and a school of applied sciences. Each school is administered by
a dean who is a professor. Each dean can administer only one
school. Therefore, a 1:1 relationship exists between PROFESSOR
and SCHOOL. Note that the cardinality can be expressed by (1,1)
for the entity PROFESSOR and by (1,1) for the entity SCHOOL.
(The smallest number of deans per school is one, as is the
largest number, and each dean is assigned to only one school.)
2. Each school is composed of several departments. For example,
the school of business has an accounting department, a
management/marketing department, an economics/nance
department, and a computer information systems department.
Note again the cardinality rules: the smallest number of
departments operated by a school is one, and the largest
number of departments is indeterminate (N). On the other hand,
each department belongs to only a single school; thus, the
cardinality is expressed by (1,1). That is, the minimum number of
schools that a department belongs to is one, as is the maximum
number.
3. Each department may oer courses. For example, the
management/marketing department oers courses such as
Introduction to Management, Principles of Marketing, and
Production Management. Note that this relationship is based on
the way Tiny College operates. If, for example, Tiny College had
some departments that were classied as “research only,” those
pf3

Partial preview of the text

Download Developing an ER Diagram: A Step-by-Step Guide for Database Design and more Lecture notes Database Management Systems (DBMS) in PDF only on Docsity!

DEVELOPING AN ER DIAGRAM

The process of database design is an iterative rather than a linear or sequential process. The verb iterates means “to do again or repeatedly.” An iterative process is, thus, one based on repetition of processes and procedures. Building an ERD usually involves the following activities: _ Create a detailed narrative of the organization’s description of operations. _ Identify the business rules based on the description of operations. _ Identify the main entities and relationships from the business rules. _ Develop the initial ERD. _ Identify the attributes and primary keys that adequately describe the entities. _ Revise and review the ERD.

To illustrate the use of the iterative process that ultimately yields a workable ERD, let’s start with an initial interview with the Tiny College administrators. The interview process yields the following business rules:

  1. Tiny College (TC) is divided into several schools: a school of business, a school of arts and sciences, a school of education, and a school of applied sciences. Each school is administered by a dean who is a professor. Each dean can administer only one school. Therefore, a 1:1 relationship exists between PROFESSOR and SCHOOL. Note that the cardinality can be expressed by (1,1) for the entity PROFESSOR and by (1,1) for the entity SCHOOL. (The smallest number of deans per school is one, as is the largest number, and each dean is assigned to only one school.)
  2. Each school is composed of several departments. For example, the school of business has an accounting department, a management/marketing department, an economics/finance department, and a computer information systems department. Note again the cardinality rules: the smallest number of departments operated by a school is one, and the largest number of departments is indeterminate (N). On the other hand, each department belongs to only a single school; thus, the cardinality is expressed by (1,1). That is, the minimum number of schools that a department belongs to is one, as is the maximum number.
  3. Each department may offer courses. For example, the management/marketing department offers courses such as Introduction to Management, Principles of Marketing, and Production Management. Note that this relationship is based on the way Tiny College operates. If, for example, Tiny College had some departments that were classified as “research only,” those

departments would not offer courses; therefore, the COURSE entity would be optional to the DEPARTMENT entity.

  1. The relationship between COURSE and CLASS was illustrated in Figure 4.9. Nevertheless, it is worth repeating that a CLASS is a section of a COURSE. That is, a department may offer several sections (classes) of the same database course. Each of those classes is taught by a professor at a given time in a given place. In short, a 1:M relationship exists between COURSE and CLASS. However, because a course may exist in Tiny College’s course catalog even when it is not offered as a class in a current class schedule, CLASS is optional to COURSE.
  2. Each department may have many professors assigned to it. One and only one of those professors chairs the department, and no professor is required to accept the chair position. Therefore, DEPARTMENT is optional to PROFESSOR in the “chairs” relationship.
  3. Each professor may teach up to four classes; each class is a section of a course. A professor may also be on a research contract and teach no classes at all.
  4. A student may enroll in several classes but takes each class only once during any given enrollment period. For example, during the current enrollment period, a student may decide to take five classes—Statistics, Accounting, English, Database, and History— but that student would not be enrolled in the same Statistics class five times during the enrollment period! Each student may enroll in up to six classes, and each class may have up to 35 students, thus creating an M:N relationship between STUDENT and CLASS. Because a CLASS can initially exist (at the start of the enrollment period) even though no students have enrolled in it, STUDENT is optional to CLASS in the M:N relationship. This M:N relationship must be divided into two 1:M relationships through the use of the ENROLL entity. But note that the optional symbol is shown next to ENROLL. If a class exists but has no students enrolled in it, that class doesn’t occur in the ENROLL table. Note also that the ENROLL entity is weak: it is existence- dependent, and its (composite) PK is composed of the PKs of the STUDENT and CLASS entities. You can add the cardinalities (0,6) and (0,35) next to the ENROLL entity to reflect the business rule constraints.
  5. Each department has several (or many) students whose major is offered by that department. However, each student has only a single major and is, therefore, associated with a single department. However, in the Tiny College environment, it is possible—at least for a while—for a student not to declare a major field of study. Such a student would not be associated with a department; therefore, DEPARTMENT is optional to STUDENT. It