this pdf excerpt

Chapter 3 Data Modeling Using the Entity-Relationship (ER) Model
In ER diagrams, total participation (or existence dependency) is displayed as a double
line connecting the participating entity type to the relationship, whereas partial
participation is representedby a single line (see Figure 3.2).
3.4.4 Attributes of Relationship Types
Relationship types can also have attributes, similar to those of entity types. For
example, to record the number of hours per week that an employee works on a particular
project, we can include an attribute Hours for the WORKS_ON relationship
type of Figure 3.13. Another example is to include the date on which a manager
started managing a department via an attribute Start-date for the MANAGES relationship
type of Figure 3.12.
Notice that attributes of I :1 or I :N relationship types can be migrated to one of the
participating entity types. For example, the Start_date attribute for the MANAGES
relationship can be an attribute of either EMPLOYEE or DEPARTMENT, although conceptually
it belongs to MANAGES. This is because MANAGES is a l:1 relationship, so
every department or employee entity participates in at most one relationship instance.
Hence, the value of the Start-date attribute can be determined separately, either by the
participating department entity or by the participating employee (manager) entity.
For a 1:N relationship type, a reiationship attribute can be migrated only to the
entity type on the N-side of the relationship. For example, in Figure 3.9, if the
WORKS-FOR relationship also has an attribute Start_date that indicates when an
employee started working for a department, this attribute can be included as an
attribute of EMPLOYEE. This is because each employee works for only one department,
and hence participates in at most one relationship instance in WORKS_FOR.
In both 1: I and l:N relationship types, the decision as to where a relationship attribute
should be placed-as a relationship type attribute or as an attribute of a participating
entity type-is determined subjectively by the schema designer.
For M:N relationship types, some attributes may be determined by the combintttion
of participating entities in a relationship instance, not by any single entity. Such
attributes must be specified as relationship attributes. An example is the Hours attribute
of the M:N relationship WORKS_ON (Figure 3.13); the number of hours an
employee works on a project is determined by an employee-project combination
and not separately by either entity.
3.5 Weak Entity Types
Entity types that do not have key attributes of their own are called weak entity
t1pes. In contrast, regular entity types that do have a key attribute-which include
all the examples we discussed so far-are called strong entity types. Entities
belonging to a weak entity type are identified by being related to specific entities
from another entity type in combination with one of their attribute values. We call
_L-