Database Reference
In-Depth Information
CLASS_CLASSROOM
CLASS
ClassID
CLASS_FACULT Y
ClassID (FK)
ClassID (FK)
FacultyID (FK)
BuildingID (FK)
ClassroomID (FK)
CourseName
Time
Semester
FACULT Y
CLASSROOM
ClassroomID
BuildingID
FacultyID
FirstName
LastName
Department
Capacity
Figure 2.14
Ternary relationship represented by binary relationships.
by a dedicated professor in a dedicated classroom, we have a one-to-one-to-one ternary relation-
ship. In the case that a particular course can only be taught in a dedicated classroom by diferent
professors, we then have a one-to-one-to-many ternary relationship. As another example, if some
courses can only be taught by one professor in several diferent classrooms, the relationship is a
one-to-many-to-many ternary relationship. In the case that more than three entities are associated
in a relationship, the relationship is an
N
-ary relationship, where
N
is an integer greater than three.
Cardinality
: Cardinality is used to specify the number of entity instances involved in a rela-
tionship. As an example, let us consider the cardinality for the relationship connecting the entities
COURSE and CLASS. From the requirement analysis, the same course can be taught in diferent
classes and each class can only teach one course. herefore, we have a nonidentifying relationship.
Figure 2.15 shows the cardinality for this relationship.
Notice that we have modiied the entities CLASS and COURSE. For instance, we removed
some attributes that will be in other entities. We changed the attribute CourseName in the CLASS
entity to CourseID due to the fact that course names may not be unique if they are ofered by dif-
ferent departments. Also, it is easier to deal with IDs with integer values. herefore, we use TimeID
for Time and SemesterID for Semester. As shown in Figure 2.15, the course instance is required
for the nonidentifying relationship since the diamond icon is not on the side of COURSE. his
means that a course ID is required for each class. he cardinality symbol
P
indicates that each
course ID is associated with one or more class instances on the child side.
As another example, let us consider the nonspeciic relationship that relates the entities
STUDENT and CLASS. According to the requirement analysis, each student can take 0-7
classes and a class has to have at least 10 students. he cardinality for CLASS is (0, 7), and the
cardinality for STUDENT is (10,
M
). Here,
M
is an integer greater than or equal to 10 and less
than the classroom capacity. In our example, let
M
be equal to 30. Figure 2.16 shows the IDEF1X
representation of these cardinalities.
CLASS
COURSE
ClassID
P
CourseID
CourseID (FK)
TimeID
SemesterID
CourseName
Credit
Description
Figure 2.15
One-or-more cardinality.
