Implementing Multi-valued Attributes

• Although the conceptual model can handle M:N relationships

and multi-valued attributes, you should not implement them
in the RDBMS.
• Each column/row intersection represents a single data
value. So if multi-valued attributes exist, the designer must
decide on one of two possible courses of action:
• Solution 1: Within the original entity, create several new
attributes, one for each of the original multi-valued
attribute’s components.
– For example, the CAR entity’s attribute CAR_COLOR can
be split to create the new attributes CAR_TOPCOLOR,
CAR_BODYCOLOR, and CAR_TRIMCOLOR, which are then
assigned to the CAR entity.
Implementing Multivalued Attributes
 Implementing Multivalued Attributes
• Although this solution seems to work, its adoption can lead to
major structural problems in the table. For example, if additional
color components—such as a logo color—are added for some cars,
the table structure must be modified to accommodate the new
color section. In that case, cars that do not have such color
sections generate nulls for the non-existing components, or
their color entries for those sections are entered as N/A to
indicate “not applicable.”
• Imagine how the solution in Figure—splitting a multi-valued
attribute into new attributes—would cause problems when it is
applied to an employee entity containing employee degrees and
certifications. If some employees have 10 degrees and
certifications while most have fewer or none, the number of
degree/certification attributes would number 10 and most of
those attribute values would be null for most of the employees.)
In short, although you have seen solution 1 applied, it is not an acceptable solution.
Implementing Multivalued Attributes
• Solution 2: Create a new entity composed of the original
multi-valued attribute’s components. The new
(independent) CAR_COLOR entity is then related to the
original CAR entity in a 1:M relationship. Note that such a
change allows the designer to define color for different
sections of the car. Using the approach illustrated in Table
4.1, you even get a fringe benefit: you are now able to assign
as many colors as necessary without having to change
the table structure.
• Note that the ERM reflects the components listed in Table
4.1. This is the preferred way to deal with multi-valued
attributes. Creating a new entity in a 1:M relationship
with the original entity yields several benefits: it’s a
more flexible, expandable solution, and it is compatible
with the relational model.
Implementing Multivalued Attributes
Derived Attributes
• Derived attribute is an attribute whose value is calculated
(derived) from other attributes. The derived attribute need
not be physically stored within the database; instead, it can
be derived by using an algorithm.
• For example, an employee’s age, EMP_AGE, may be found by
computing the integer value of the difference between the
current date and the EMP_DOB.
• If you use Microsoft Access, you would use the formula
INT((DATE() – EMP_DOB)/365). In Microsoft SQL Server,
you would use SELECT DATEDIFF(“YEAR”, EMP_DOB,
GETDATE()); where DATEDIFF is a function that computes
the difference between dates. The first parameter indicates
the measurement, in this case, years.
Derived Attributes
• If you use Oracle, you would use SYSDATE instead of
DATE(). assuming, of course, that the EMP_DOB was
stored in the Julian date format.
• Similarly, the total cost of an order can be derived by
multiplying the quantity ordered by the unit price. Or
the estimated average speed can be derived by dividing
trip distance by the time spent en route.
• A derived attribute is indicated in the Chen notation by
a dashed line connecting the attribute and the entity.
• The Crow’s Foot notation does not have a method for
distinguishing the derived attribute from other
attributes.
Derived Attributes
Derived Attributes
• Derived attributes are sometimes referred to as
computed attributes. A derived attribute
computation can be as simple as adding two
attribute values located on the same row, or it can
be the result of aggregating the sum of values
located on many table rows (from the same table or
from a different table).
• The decision to store derived attributes in database
tables depends on the processing requirements
and the constraints placed on a particular
application. The designer should be able to balance
the design in accordance with such constraints.
Derived Attributes
Relationships
• A relationship is an association between entities. The
entities that participate in a relationship are also known as
participants, and each relationship is identified by a name
that describes the relationship. The relationship name is an
active or passive verb; for example, a STUDENT takes a
CLASS, a PROFESSOR teaches a CLASS, a DEPARTMENT
employs a PROFESSOR, a DIVISION is managed by an
EMPLOYEE, and an AIRCRAFT is flown by a CREW.
• Relationships between entities always operate in both
directions. That is, to define the relationship between the
entities named CUSTOMER and INVOICE:
– A CUSTOMER may generate many INVOICEs.
– Each INVOICE is generated by one CUSTOMER.
– Relationship can be classified as 1:M.
Relationships
Another Example:
• The relationship classification is difficult to establish if only
one side of the relationship is known. For example, if :
– A DIVISION is managed by one EMPLOYEE.
• Don’t know if the relationship is 1:1 or 1:M. Therefore,
should ask the question “Can an employee manage more
than one division?” If the answer is yes, the relationship is
1:M, and the second part of the relationship is the written as:
– An EMPLOYEE may manage many DIVISIONs.
• If an employee cannot manage more than one division, the
relationship is 1:1, and the second part of the relationship is
then written as:
– An EMPLOYEE may manage only one DIVISION.
Connectivity and Cardinality
• Entity relationships may be classified as one-to-one, one-to-
many, or many-to-many.
• The term connectivity is used to describe the relationship
classification.
• Cardinality expresses the minimum and maximum number
of entity occurrences associated with one occurrence of
the related entity. In the ERD, cardinality is indicated by
placing the appropriate numbers beside the entities, using the
format (x, y). The first value represents the minimum
number of associated entity occurrences, while the second
value represents the maximum number of associated
entity occurrences.
• Some Crow’s Foot ER modeling tools do not print the numeric
cardinality range in the diagram; instead, you could add it as
text. In Crow’s Foot notation, cardinality is implied by the use
of symbols in Figure in the next slide.
Connectivity and Cardinality
• The numeric cardinality range has been added using the
Visio text drawing tool.
Connectivity and Cardinality
• Knowing the minimum and maximum number
of entity occurrences is very useful at the
application software level. For example, Tiny
College might want to ensure that a class is not
taught unless it has at least 10 students enrolled.
• Similarly, if the classroom can hold only 30
students, the application software should use that
cardinality to limit enrollment in the class.
However, keep in mind that the DBMS cannot
handle the implementation of the cardinalities
at the table level—that capability is provided by
the application software or by triggers.
Connectivity and Cardinality
• Examine the Crow’s Foot diagram in Figure 4.7, keep in mind
that the cardinalities represent the number of
occurrences in the related entity.
• For example, the cardinality (1,4) written next to the
CLASS entity in the “PROFESSOR teaches CLASS”
relationship indicates that the PROFESSOR table’s
primary key value occurs at least once and no more than
four times as foreign key values in the CLASS table. If the
cardinality had been written as (1,N), there would be no
upper limit to the number of classes a professor might teach.
Similarly, the cardinality (1,1) written next to the
PROFESSOR entity indicates that each class is taught by
one and only one professor. That is, each CLASS entity
occurrence is associated with one and only one entity
occurrence in PROFESSOR. Connectivities and cardinalities
are established.
Connectivity and Cardinality