Database Reference
In-Depth Information
2.3.4 Relationships
Objects in a business process are often related as shown in the requirement analysis section.
herefore, entities' relationships are logically represented in the data model according to how
they are related in the business process. he relationship component in the E-R model is used
to describe how entities are associated with each other. In the IDEF1X standard, relationships are
classiied into several diferent types. he descriptions of some of the commonly used relationships
are given below. We will start with the identifying relationship.
Identifying relationship : To understand this kind of relationship, let us examine how the
entity CLASSROOM is related to the entity BUILDING. Since two classrooms in two diferent
buildings may have the same classroom number, the business rule requires that the CLASSROOM
entity should include the building identiier as part of its own identiier. hat is, the classroom
identiier depends on the existence of the building identiier. In such a case, the CLASSROOM
entity is called a weak entity . An identifying relationship relates two entities and one of them is
a weak entity. In our example, the CLASSROOM entity is the weak entity that depends on the
existence of the parent entity BUILDING. To represent the identifying relationship in IDEF1X,
use the symbols in Figure 2.6.
In Figure 2.6, the parent entity is represented by a rectangle, and the weak entity is represented
by a round-cornered rectangle. he identifying relationship is represented by a solid line. he
entity attached to a illed-in black dot is the child entity. he attribute BuildingID is the key for
the entity BULDING. he combination of ClassroomID and BuildingID is the key for the entity
CLASSROOM. he symbol (FK) indicates that the key attribute BuildingID is from a foreign
entity called a foreign key. In the identifying relationship, it is required that the key of the child
entity always includes the key of the parent entity, which makes the child entity a weak entity.
Nonidentifying relationship : From the requirement analysis, we have discovered that the
entity STUDENT is related to the entity FACULTY. A faculty member may advise zero, one or
many students and a student may or may not have an advisor. Such a relationship is diferent from
the identifying relationship. In this relationship, each student, that is, an instance of the entity, is
given zero or one faculty ID. he key attribute of the STUDENT entity does not need to include
the key attribute from the FACULTY entity. his kind of relationship is called a nonidentifying
relationship . he IEDF1X representation of the nonidentifying relationship is given in Figure 2.7.
Notice that, to relate these two entities, the attribute FacultyID is added to the STUDENT
entity. In the IDEF1X standard, the two entities are associated by a relationship sharing a common
attribute. Again, a illed-in black dot indicates that STUDENT is the child entity. he dashed
line means that the relationship is a nonidentifying relationship. he diamond sign on the side of
the FACULTY entity indicates that an advisor is optional. Usually, a nonidentifying relationship
is used to represent a relationship where one entity instance in an entity relates to several entity
instances in another entity. his type of relationship is often a one-to-many (1: N ) relationship,
CLASSROOM
ClassroomID
BUILDING
BuildingID
BuildingID (FK)
BuildingName
Capacity
Figure 2.6
Identifying relationship.
Search WWH ::




Custom Search