There are several ways we can represent and document systems and processes. Looking at a system in different ways can help increase the overall understanding for different team members.

This article looks at two ways of representing systems using diagrams: Unified Modeling Language (UML) deployment diagrams, and entity-relationship diagrams (ERD). We’ll start by defining each, and then go on to discuss their similarities and differences.

UML Deployment Diagrams

A UML deployment diagram shows execution architecture. Execution architecture includes nodes such as hardware and software environments, the middleware connecting them, the links of communication, and the placement of files on the hardware. This helps visualize how we have deployed or how we intend to deploy the software on the hardware. 

The most commonly used components of UML deployment diagrams are:

• Nodes
• Artifacts
• Communication path
• Devices
• Deployment specifications

Let’s define each and see how to represent them in a diagram.

Nodes

A node is a physical entity. It could be a hardware or software element that executes one or more components, subsystems, or executables. It’s also known as a deployment target.

Artifacts  

An artifact is an element that represents some physical entity. A development process produces it. Examples of artifacts are scripts, libraries, executable files, and configuration files.

Communication Path

A communication path is a channel between two deployment targets, through which they can exchange signals and messages. It represents the communication path between the two nodes with a solid line.

Devices

A device is a node that represents a physical computational resource in a system, one with processing capability to which we deploy artifacts for execution. Examples include mobile devices or application servers.

Deployment Specification 

A deployment specification is an artifact. One example is a text file or an XML document that specifies how to deploy an artifact on a node. 

Entity-Relationship Diagrams 

An ERD is a type of flowchart that, as its name suggests, illustrates the relationships of entities stored in a database. An entity is an object—a component of data—that contains attributes that define its properties. It represents the storage of data in the database. A collection of similar entities is an entity set. 

ERDs sketch out, model, and design relational databases in logic and business rules. An ERD illustrates the logical structure of a database by defining the entities and their attributes, and shows the relationships between them.  

The five main components of an ERD are:

• Entities
• Actions
• Attributes
• Connecting lines
• Cardinality. 

Let’s look at each of these in detail. 

Entities

As we’ve seen, entities represent the data to be stored. We can think of an entity as a noun: a person, place, or thing. An entity represents a database table. An entity that isn’t defined entirely by its own entities is called a weak entity. A foreign key relationship with another entity needs to specify the value of the key. 

Actions

An action, known as a relationship, shows how entities act upon each other and share information in the database. They represent the relationship between two entities.

Attributes

An attribute is a property or characteristic of an entity. The entity’s attributes are fields in a database table. A key attribute is a uniquely distinguishing characteristic of an entity. 

Multivalued attributes can have more than a single value. A derived attribute is one whose value we calculate from another. For example, we can derive an average course rating from the sum of ratings divided by the number of ratings. Derived attributes shouldn’t exist in the database — only their source attributes should.

Connecting Lines

Connecting lines are solid lines that connect attributes to show the relationships of entities in the database.

Cardinality 

Cardinality is the specification of how many instances of an entity are related to another entity or entity set. Here are examples of the three primary cardinal relationships:

• One-to-one: one student can have one desk 
• One-to-many: one student can register for many courses 
• Many-to-many: many students can have many teachers

Differences and Similarities 

From what we’ve discussed, the most obvious difference is the levels at which we use these two diagrams. 

UML deployment diagrams provide an overall picture of the system, show the relationship between the various physical components within the system, and model the system’s runtime architecture. They describe the hardware components that we use to deploy the software components. 

ERDs, on the other hand, describe and visually present database entities and how these entities are related to one another. So, they help to explain the logical structure of the database. A UML deployment diagram assists with designing a system, and an ERD helps to design the database. 

When to Use UML Deployment Diagrams and Entity Relationship Diagrams

Using UML Deployment Diagrams

Developers, DevOps engineers, system administrators, and network engineers use UML deployment diagrams. They tend to differ based on who uses them and how people think diagrams help them create systems. 

The primary purpose of these diagrams is to show the installation of software on the hardware and to show how the software interacts with the hardware to execute. Showing this is important because software applications are complex. We can have standalone, web-based, or distributed systems, to name a few. Or we can have a combination of these. 

We can use UML deployment diagrams for:

• Modeling the hardware topology of a system 
• Modeling hardware details for a client and server system 
• Modeling the hardware details of a system 

Let’s look at an example of a deployment diagram that represents how we can deploy feature flags. Feature flagging is a technique that enables the modification of system behavior without changing code. It enables us to turn functionality on and off during runtime. 

We can deploy these feature flags using a configuration file that stores global application settings. But suppose we have many flags or need more granular control of our application. In that case, we can deploy flags using a database to target individual users.

Now, let’s look at a deployment diagram using a database. Notice how the deployment diagram doesn’t focus on the logical components of the system but instead draws attention to the hardware topology. 

Using ERDs 

Entity-relationship diagrams are handy for businesses with complex databases. Analysts and developers use them to define and analyze how data is set up in a particular system. They can be a great way to communicate the business landscape to different teams. Because ERDs graphically represent data, it makes it easier for business people to understand.  

We can use ERDs for: 

• Gathering requirements 
• Designing, maintaining, and modifying a database 
• Communicating data requirements 

The following is an example of a simple ERD representing a course enrollment system. It shows the models with their attributes and their relationship with each other. The diagram indicates that many users can study many courses, and one teacher can teach many courses.

Conclusion

This article discussed UML deployment diagrams and entity-relationship diagrams. The main difference between the two is that we use UML deployment diagrams to model a system’s hardware and its interaction with the software deployed on it. In contrast, we use ERDs to model databases and the relationship of their entities. Understanding this makes it easy to choose the right tools. 
For more examples of ERDs, see Entity Relationship Modeling Examples, and for more elaborate examples of ULM , visit UML Deployment Diagrams Examples.