Database Processing:

Fundamentals, Design, and Implementation

12th Edition

David M. Kroenke David J. Auer

Online Appendix D
E-R Diagrams and the UML Standard
Database Processing Appendix D

Appendix D 10 9 8 7 6 5 4 3 2 1

D-2
Database Processing Appendix D

Chapter Objectives

To understand UML-style E-R diagrams

To be able to model HAS-A, nonidentifying, identifying, and IS-A relationships using UML
symbols
To understand the object-oriented programming language constructs used in UML

What is the Purpose of this Appendix?

The Unified Modeling Language (UML) is a set of structures and techniques for modeling and designing
object-oriented programs (OOP) and applications. UML has come to prominence due to the Object
Management Group, an organization that has been developing OOP models, technology, and standards
since the 1980s. It is also beginning to see widespread use among OOP practitioners. In this appendix,
we are primarily interested in understanding the UML notation, and how it relates to IE Crows Foot no-
tation.

Why Should I Learn to Use UML?

Because it is an application development methodology, UML is a subject for a course on systems devel-
opment and is of limited concern to us. However, some UML diagrams are used to model database de-
signs, and you may encounter them during your career. Accordingly, you should be familiar with their
style.

What Will This Appendix Teach Me?

In this appendix you will learn the differences between the extended E-R model and UML-style E-R dia-
grams, and how to use UML to create data models.

D-3
Database Processing Appendix D

Figure D-1: UML Representation of HAS-A Relationships

How Does UML Represent Entities and Relationships?

Figure D-1 shows the UML representation of a 1:1, a 1:N, and an N:M HAS-A relationship. Each entity is
represented by an entity class, which is shown as a rectangle with three segments. The top segment
shows the name of the entity and other data that we will discuss. The second segment lists the names of
the attributes in the entity, and the third documents constraints and lists methods (program proce-
dures) that belong to the entity.

Relationships are shown with a line between two entities. Cardinalities are represented in the x..y car-
dinality format, where x is the minimum required and y is the maximum allowed. Thus, 0..1 means that
no entity is required and that at most one is allowed. An asterisk represents an unlimited number. Thus,
1..* means that one is required and an unlimited number is allowed.

D-4
Database Processing Appendix D

Figure D-2: UML Representation of Weak Entities

Representation of Weak Entities

Figure D-2 shows the UML representation of weak entities. A filled-in diamond is placed on the line to
the parent of the weak entity (the entity on which the weak entity depends). In Figure D-2(a), PRESCRIP-
TION is the weak entity and PATIENT is the parent entity. All weak entities have a parent, so the cardi-
nality on their side of the weak relationship is always 1..1. Because of this, the cardinality on the parent
entity is shown simply as 1.

Figure D-2(a) shows a weak entity that is not an ID-dependent entity. It is denoted by the expression
<nonidentifying> on the PATIENT-PRESCRIPTION relationship. Figure D-2(b) shows a weak entity that is
ID-dependent. It is denoted with the label <identifying>.

Representation of Subtypes

UML represents subtypes and IS-A relationships, as shown in Figure D-3. In this figure, INDIVIDUAL,
PARTNERSHIP, and CORPORATE subtypes of CLIENT are allowed. According to this figure, a given CLIENT
could be one, two, or three of these subtypes. This does not make sense for this particular situation; a
CLIENT should be one and only one of these types. The current version of UML does not provide a
means to document exclusivity. Such notation can be added to a UML diagram, however.

D-5
Database Processing Appendix D

Figure D-3: UML Representation of HAS-A Relationships

What Object-Oriented Programming Constructs are Introduced by UML?

Because UML is an object-oriented technology, several Object-Oriented Programming (OOP) constructs

have been added to UML entity classes. We will touch on these ideas here; you will learn more about
them when you study object-oriented systems development. Consider the UML diagram in Figure D-4,
which shows an E-R diagram with the full UML decoration.
First, the classes of all entities that are to be stored in the database are labeled with the keyword <<Per-
sistent>>. This simply means that data should continue to exist even if the object that processes it is de-
stroyed. In simpler terms, it means that the entity class is to be stored in the database.

Figure D-4: UML Representation of HAS-A Relationships

D-6
Database Processing Appendix D

Next, UML entity classes allow for class attributes. Such attributes differ from entity attributes because
they pertain to the class of all entities of a given type. Thus, in Figure D-4 PatientCount of PATIENT is an
attribute of the collection of all PATIENTs in the database. PatientSource is an attribute that documents
the source of all of the PATIENTs in the database.

As you will learn, such class attributes have no place to reside when using the relational model. Instead,
in some cases, attributes such as PatientCount are not stored in the database but are computed at run
time. In other cases, a new entity is introduced to contain the class attributes. For the entity in Figure D-
4, a new entity called PATIENT-SOURCE could be defined to hold both PatientCount and PatientSource
attributes. In this case, all of the entities in PATIENT are connected to PATIENT-SOURCE.

A third new feature is that UML uses object-oriented notation for the visibility of attributes and meth-
ods. Attributes preceded by a + are public, those with a # are protected, and those with a are private.
Thus in Figure D-4, Name in PATIENT is a protected attribute. These terms arise from the discipline of
object-oriented programming. A public attribute can be accessed and changed by any method of any
object. A public method can be invoked by any method of any object. Protected means that the attrib-
ute or method is accessible only by methods of this class or of its subclasses, and private means that the
attribute or method is accessible only by methods of this class.

Finally, UML entities specify constraints and methods in the third segment of the entity classes. In Figure
D-4, a primary key constraint is placed on PatientID. This simply means that PatientID is a unique identi-
fier. Additionally, Figure D-4 documents that GetName() is to be created to provide public access (note
the + in front of GetName) to the Name attribute; SetName() is to be used to set its value; and the
method GetPrescription() can be used to iterate over the set of Prescription entities related to this PA-
TIENT entity.

What is The Role of UML in Database Processing Today?

The ideas illustrated in Figure D-4 lie in the murky water where database processing and object-oriented
thinking merge. Such object-oriented notation does not fit with the practices and procedures of com-
mercial database processing today. The notion that an entity attribute can be hidden in an object does
not make sense unless only object-oriented programs are processing the database; even then, those
programs must process the data in conformance with that policy. This is almost never done.

Instead, most commercial DBMS products have features that allow all types of programs to access the
database and process any data that they have permission to access. Moreover, with facilities such as
SQL, there is no way to limit access to attribute values to a single object.

So, the bottom line is that you should know how to interpret UML-style E-R diagrams. They can be used
for database design just as extended E-R diagrams can. At present, however, the object-oriented nota-
tion they introduce is of limited practical value to database practitioners. The extended E-R model using
the crows foot notation is far more common and useful for database (as opposed to OO) design.

D-7
Database Processing Appendix D

Key Terms

<<persistent>> <identifying>

<nonidentifying> class attributes

entity class HAS-A relationship

IS-A relationship private

protected public

Unified Modeling Language (UML) x..y cardinality format

Review Questions

D.1 Why is UML important? Why is it of concern to database designers?

D.2 Show a 1:1 relationship in UML format.
D.3 Show a 1:N relationship in UML format.
D.4 Show an N:M relationship in UML format.
D.5 Explain how UML documents minimum cardinality.
D.6 Show identifying and nonidentifying weak entities in UML format.
D.7 Show subtypes in UML format.
D.8 What are class attributes? How are they documented in UML?
D.9 How would class attributes be represented in the extended E-R model described in
Chapter 5?
D.10 Explain the significance of the +, #, and signs in a UML diagram.
D.11 Give an example of a constraint on an entity in a UML diagram.
D.12 Redraw the E-R diagram in Figure 5-52 using UML.
D.13 Describe the ways in which UML and commercial database processing are misfits. How
do you think this situation will be resolved?
D.14 Answer Review Question 5.58, but use UML instead of the crows foot model.
D.15 Answer Review Question 5.62, but use UML instead of the crows foot model. Redraw
Figure 5-58 using UML notation.

D-8