Entity Relationship Modeling with UML

A technical discussion on modeling with UML
06/11/03
Entity Relationship
Modeling with UML
Davor Gornik

---

Improving software development capability
2
Table of Contents
Entity Relationship Modeling............................................................................................................... 1
Core Elements of ER Modeling........................................................................................................... 1
Entity Types .............................................................................................................................................1
Attributes .................................................................................................................................................2
Relationship Types ...................................................................................................................................2
Attributes of Relationship Types ................................................................................................................3
Simple Constraints in ER Modeling ............................................................................................................4
Cardinality ................................................................................................................................................4
Dependency ............................................................................................................................................6
Specialization and Generalization...............................................................................................................7
Specialization and Generalization...............................................................................................................7
Categorization ..........................................................................................................................................8
Notations for the ER Methodology..................................................................................................... 9
Entity Types in UML ..................................................................................................................................9
Attributes in UML ....................................................................................................................................10
Relationship Types in UML ......................................................................................................................10
Attributes of Relationship Types in UML ...................................................................................................11
Simple Constraints in UML.......................................................................................................................11
Cardinality ..............................................................................................................................................11
Dependency ..........................................................................................................................................12
Specialization and Generalization.............................................................................................................12
Categorization ........................................................................................................................................13
Summary................................................................................................................................................14

---

Entity Relationship Modeling
One of the most misinterpreted terms in the software industry is actually one we know very well: entity relationship (ER).
That’s because we often lack a common definition that is understood by all members of the development team. We assume
that everyone on the team shares the same clear understanding of the methodology, syntax, and mechanics associated with
ER and ER modeling.
ER modeling itself defines the methodology used in the analysis and design of information-based systems. Database
designers often use this methodology to gather requirements and define the architecture of the database systems. The output
of this methodology is a list of entity types, relationship types, and constraints.
Unfortunately, ER modeling does not define the graphic syntax for the representation of ER diagrams. Many times notations
are used solely by the database team and limit the ER modeling to relational database design. We need a notation that allows
broader understanding by members of the entire system development team.
The Unified Modeling Language (UML) is a widely accepted language used by analysts and software developers that is an
excellent fit for the graphic representation of ER diagrams. By using UML, development teams gain significant benefits,
including easier communication between team members, easy integration to repositories due to this language based on meta-
models, use of a standardized input/output format (XMI), universal use for application and data modeling, unified
representation from analysis to implementation to deployment, and completeness of specification.
This white paper defines the core concepts of ER modeling and explains how UML can be used by development teams to
develop ER models.
Core Elements of ER Modeling
ER modeling is based on artifacts, which can be either a representation of physical artifacts, such as Product or Employee, or
a representation of a transaction between artifacts, such as Order or Delivery. Each artifact contains information about itself.
ER modeling also focuses on relationships between artifacts. These relationships can be either binary, connecting two
artifacts, or ternary, among several artifacts.
The four essential elements of ER modeling are:
•
Entity types
•
Attributes
•
Relationship types
•
Attributes on relationships
Entity Types
An entity type is a set of artifacts with the same structure and independent existence within the enterprise. Examples of an
entity type would be Employees or Products.
A single occurrence of an artifact is an entity. While an entity type describes the structure, the entity itself identifies the
single instance and all of the data of this instance. An example of an Employees entity would be the Employee Joe Ward.
1

---

Figure 1 Entity Type Employees and Entity Employee Joe Ward
Attributes
The structure of an entity type is defined with attributes. An attribute can be seen as a property of an entity type. Attributes
of an Employee might be Name, Address, Social Security Number, Birth Date, Date Joined, and Position.
Entities differ from each other by the values of their attributes. Since it is possible to have entities with exactly the same
values for attributes, we lose the ability to differentiate and address a specific entity. Therefore, we must always make sure
that the values of attributes of a specific entity are unique to values of other entities. Each Employee has a unique
combination of Name and Social Security Number attributes.
An example of associated values for attributes of an Employee is: Joe Ward, living at 34 Main Road, Redmond, WA,
98053, has the Social Security Number 555-32-2222, was born on September 7, 1971, and joined our company October 1,
2001, as a service engineer for consumer electronics.
Figure 2 Attributes of the entity types Employees and the values for attributes
for the entity Employee Joe Ward
Relationship Types
While entity types describe independent artifacts, relationship types describe meaningful associations between entity types.
To be precise, the relationship type describes that entities of entity types participating in the relationship can build a
meaningful association. The actual occurrence of the association between entities is called a relationship.
It is important to understand that although we defined a relationship type, this does not mean that every pair of entities
builds a relationship. A relationship type defines only that relationships can occur.
2

---

An example of a relationship type is the Employee owns Product. In this example the relationship type is Owns. The
relationship itself is: The Employee Joe Ward owns a Product, the yellow Telephone, with the Serial Number 320TS03880.
Figure 3 Relationship Type owns and Relationship owns between Employee Joe Ward
and the Product with the serial number 320TS03880
There might be a second employee Martin Weber who does not own a Telephone.
Attributes of Relationship Types
Relationship types can also contain attributes. For example the relationship type Services between the Employee and the
Product could contain the attributes Date and Status, which identify the date of the service and the status of the product after
the service is done.
When the relationship is realized in a concrete occurrence of the service, the values of the attributes of the relationship are set.
The meaning of the relationship could be: Joe Ward services the black Toaster with the Serial Number 0462834DF4 on July
3, 2002, and establishes the status as good working condition.
3

---

Figure 4 Attributes on Relationship Type services and Attributes on Relationship Joe Ward
services Product with the Serial No 0462834DF4
Simple Constraints in ER Modeling
Entities, relationships, and attributes within the ER model establish restrictions that define the structure of the enterprise.
The structure is limited by rules called constraints. For example, it is not feasible that an Employee deals with more than
100 customers. Or, every employee must be associated with exactly one department.
Cardinality
Each specified relationship type defines the possibility of establishing relationships between all of the participating entities.
In most cases, this is not necessary. For example, not all Employees own all of the Products.
Relationships are bi-directional, connecting two entity types (Employees and Products) or the same entity type playing two
different roles (Employees as a manager and Employees as a subordinate). Relationships can also be multi-directional,
connecting more than two entity types. One example of a multi-directional relationship would be a phone call connecting an
employee, a customer, and two phones. In either case, each entity type specifies the cardinality towards the relationship type.
The simplest cardinality is specified by the number of relationships allowed per entity. If only one Department participates in
the relationship associated with an Employee, we write a 1 on the connector. This would mean that Joe Ward must be
associated with one and only one Department.
Other possibilities for cardinality are either Not Specified or Specified By a Variable. The Not Specified cardinality is
unlimited. The same is true for a cardinality Specified By a Variable (mostly M or N).
When the lower and upper limits of participating entities in a relationship are different, we specify a pair of values for the
lower and higher limits enclosed in parenthesis and separated by a comma (M, N). An optional relationship would be
recognized by (0, 1) or (0, N) dependent on the upper limit.
For example, a setup for Players on a Soccer team would be something like (11, 18). The entity Redmond Lions Soccer
Team builds a relationship to the entity type Players, which consists of Joe Coplen, David Archer, John Good, Kevin Hale,
Ivan Komashinsky, Steven Cooper, Andrew Bliven, Art Lounsbery, Chad Beery, Randall DuBois, Ron Baghai, Lance Delo,
Tito Magobet, Curtis Hrischuk, and Ian Leslie.
4

---

Figure 5 The Relationship between Soccer Teams and Players defines that the relationship is valid
only when the Soccer Teams type relates to 11 to 18 Players
Figure 6 A valid relationship is team member between the Redmond Lions soccer club and 15
Players
5

---

There are several occasions when soccer players receive yellow or red cards for bad behavior or fouls. They are described in
the Cards entity type. The Cards entity type builds a Received relationship type with Players with a cardinality of (0, N).
This means that the Player David Archer can have a Received relationship to 3 Card entities, whereas Lance Delo does not
have any.
Figure 7 Entity type Players can Receive 0 or any number of entity type Cards: player David
Archer received 3 cards, player Lance Delo did not receive any cards yet
Dependency
Dependency refers to a situation in which a particular entity can not meaningfully exist without the existence of another
entity as specified within a relationship. The entity type is dependent on another entity type when each entity of a dependent
entity (subtype) depends on the existence of the corresponding parent entity in the super type.
A mandatory dependency relationship has to be specified by explicitly defining the lower limit for cardinality that is not
equal to 0 or by a fixed cardinality that is not equal to 0.
An example of a dependency between two entities would be the entity type Marriage Certificate, which depends on the entity
type Person. The relationship is Married with a fixed dependency on one Marriage Certificate and two Persons.
For example, the entity Marriage Certificate 352647003 has a fixed dependency to entities Joe Ward and Melinda Bell. This
means that if either Melinda Bell or Joe Ward leaves the relationship, the Marriage Certificate 352647003 becomes invalid –
at least from the data point of view.
6

---

Figure 8 Dependent entity type Marriage Certificate on the entity type Persons and dependency of
the entity Marriage Certificate 352647003 on Melinda Bell and Joe Ward
Specialization and Generalization
The core ER model defines only basic relationships between entity types. While the basic entities and relationships can
easily represent most of the simple data structures in business organizations, technical applications require more complex
structures based on similarity and differences between entity types.
Specialization and Generalization
The intent of specialization and generalization is reuse of the attributes and behaviors associated with entity types.
Specialization is used to define an entity type that represents a specific segment of a larger entity type. The specialized entity
type inherits the structure and behavior, such as business rules, from the parent entity type. However, while the specialized
entity type extends the parent structure or behavior, it is never less than the parent.
For example, Employees is a specialization of the entity type Persons, which requires all of the attributes and relationships
of the entity type Persons. There may also be a second entity type called Customers that is a specialization of the entity type
Persons. Both entity types have the same Persons attributes, which are seen as attributes of Employees or attributes of
Customers. Therefore, when looking at the Customers, we see all of the attributes specified in the Persons entity type and
specified in the Customers entity type.
Generalization is exactly the opposite workflow. The generalized entity type (or parent type) represents the common structure
and behavior of all subtypes and contains all of the common attributes from child entity types. The child entity types have a
complete view of the parent attributes and their own attributes.
The process of generalization finds the common structure and extracts it in the parent entity type. The parent entity type is
commonly found during refactoring when comparing entity types and simplifying the model.
While specialization can be directly implemented only with object-oriented or object-relational databases, generalization can
be directly implemented with any relational database using foreign keys.
7

---

Figure 9 Generalization of Customers entity type and Employees entity type to Persons entity type;
Specialization works in the opposite direction
Categorization
While specialization is done on entities, categorization defines constraints on relationship types. In most cases, categorization
is exclusive, meaning that one entity participates in either relationship A or relationship B, depending on the entities’ status.
The status can be either a value of an attribute, a presence of another relationship, or some external status.
Categorization does not change the attributes of an entity. It requires the data access and manipulation to consider the
constraints specified in the categorization.
A good example of categorization is Vehicles. Depending on the kind of vehicle, we need to build different relationships.
For trucks, we need the cargo information, while for busses, we need the names of passengers. This information will be used
in different relationships to deliver meaningful context to the relationship.
8

---