For some, Entity Relationship Diagrams (ERDs) are old friends that you still visit once in a while and have some fun with. For others…not so much. Let’s try to help the latter get up to speed on ERDs.

An Entity Relationship Diagram (ERD) is a visual representation of different data using conventions that describe how these data relate to each other. While able to describe just about any system, ERDs are most often associated with the complex databases used in software engineering and IT networks. In particular, ERDs are frequently used during the design stage of a development process to identify different system elements and their relationships to each other. As you might imagine, this can be particularly helpful when modernizing a database.

There are three basic elements in an ERD: entity, attribute, and relationship. There are more elements based on these three main elements. They are weak entity, multivalued attribute, weak relationship, derived attribute, and recursive relationship. All but the last two of these elements are shown in Figure 1. I’ll talk about derived attributes and recursive relationships later.

Figure 1: ERD basic elements

What’s an Entity, Anyway?

Let’s take a quick tour of these elements, starting with the entity. An entity can be a person, place, event, or object that is relevant to a given system. For example, in an inventory system, entities might include clients, suppliers, warehouses, items, and fees. Entities are represented in ERDs by rectangles and named using singular nouns. A weak entity is a special type of entity that depends on the existence of another entity. In more technical terms, it can be defined as an entity that cannot be identified by its own attributes. It uses a foreign key combined with its attributes to form the primary key. For example, an order item is a good example of this type of entity. It is meaningless without an order, so it depends on the existence of order.

Typically, entities have attributes, the same way a record has fields. An attribute is a property, trait, or characteristic of an entity, relationship, or another attribute. For example, an inventory item entity can have the attribute “inventory item name." An entity can have as many attributes as necessary, and attributes can have their own specific attributes. For example, the customer address attribute can have the attributes number, street, city, and state. These are called composite attributes.

Some top-level Entity Relationship Diagrams do not show attributes, for the sake of simplicity. In those that do, however, attributes are represented by ovals, as shown in Figure 2.

Figure 2: An example of ERD attributes representation

You must distinguish between composite attributes, like the address attribute in Figure 2, and multivalue attributes. A multivalue attribute can have more than one value at the same time. Because it’s not very practical in database systems, it’s usually implemented in the physical model using primary and secondary tables, like the Client Master and Client Address tables from the 1NF example from the previous article.

Let’s use normalization to explain yet another variation of the attribute: the derived attribute. This is simply an attribute based on another attribute. A good example of this is the item weight in kilograms from the 3NF example. Because you can calculate the weight in kilograms from the weight in pounds, you can say that the first one derives from the second. If you were to represent that table in an ERD, you would use the derived attribute notation, an ellipse with a dashed outline. This is rarely found in ERDs.

Relationships—Some Are Simple, Some Are Complex

Now that we’ve covered the entity element of the diagram name, let’s move on to the relationship, starting with a generic definition of what a relationship is: a relationship describes how entities interact. For example, the client entity may be related to the order entity by the relationship “places” or “makes.” Relationships are represented by diamonds and are labeled using verbs. However, an entity can also have a relationship with itself. For instance, an employee entity could contain an attribute called “supervisor” and have a relationship with itself that defines the hierarchical structure. This is a recursive relationship, as shown in Figure 3.

Figure 3: An example of a recursive relationship.

Here, the “Supervises” recursive relationship indicates that an employee is supervised by another employee. However, this is not enough to fully represent how the relationship works, because it only describes that a relationship exists between two entities. To fully represent the relationship, you need to define its cardinality. In other words, you need to explicitly show how the information from one entity in a relationship matches the information from the other entity.

For instance, in the Client Master/Client Address scenario, a Client Master record can have one or more matching records (records with the same client ID) in the Client Address table. This is a “one-to-many” relationship. On the other hand, each Client Address record can only match one record in the Client Master table. This represents a “one-to-one” relationship. A number of notations are used to present cardinality in ERDs. Chen, UML, Crow’s Foot, and Bachman are some of the popular notations.

Tips for Creating Good ERDs

Because Entity Relationship Diagrams are simple enough to understand, just about anyone can create them. However, two different ERDs describing the same system may still be radically different in terms of their simplicity, completeness, and efficiency at communicating the system. In other words, there are good ERDs, and there are really bad ones. Here are some tips that will help you build effective ERDs:

• Identify all the relevant entities in a given system and determine the relationships among these entities.
• An entity should appear only once in a diagram.
• Provide a precise and appropriate name for each entity, attribute, and relationship in the diagram. Terms that are simple and familiar always beat vague, technical-sounding words. In naming entities, remember to use singular nouns. However, adjectives may be used to distinguish entities belonging to the same class (part-time employee versus full-time employee, for example).
• Attribute names must be meaningful, unique, system-independent, and easily understandable.
• Remove vague, redundant, or unnecessary relationships between entities.
• Never connect a relationship to another relationship.
• Make effective use of colors. You can use colors to classify similar entities or to highlight key areas in your diagrams.

You can draw Entity Relationship Diagrams manually, especially when you are just informally showing simple systems to your peers. However, for more complex systems and for external audiences, you need diagramming software to craft visually engaging and precise ERDs. Some of the tools presented in the next article will help with that. Until then, please share your experience, questions, and thoughts using the comments section below. You might help a fellow reader or even find that piece of information you’ve been looking for!

Rafael Victória-Pereira has more than 20 years of IBM i experience as a programmer, analyst, and manager. Over that period, he has been an active voice in the IBM i community, encouraging and helping programmers transition to ILE and free-format RPG. Rafael has written more than 100 technical articles about topics ranging from interfaces (the topic for his first book, Flexible Input, Dazzling Output with IBM i) to modern RPG and SQL in his popular RPG Academy and SQL 101 series on mcpressonline.com and in his books Evolve Your RPG Coding and SQL for IBM i: A Database Modernization Guide. Rafael writes in an easy-to-read, practical style that is highly popular with his audience of IBM technology professionals.

Rafael is the Deputy IT Director - Infrastructures and Services at the Luis Simões Group in Portugal. His areas of expertise include programming in the IBM i native languages (RPG, CL, and DB2 SQL) and in "modern" programming languages, such as Java, C#, and Python, as well as project management and consultancy.

---

MC Press books written by Rafael Victória-Pereira available now on the MC Press Bookstore.

		Evolve Your RPG Coding: Move from OPM to ILE...and Beyond Transition to modern RPG programming with this step-by-step guide through ILE and free-format RPG, SQL, and modernization techniques. List Price $79.95 Now On Sale
		Flexible Input, Dazzling Output with IBM i Uncover easier, more flexible ways to get data into your system, plus some methods for exporting and presenting the vital business data it contains. List Price $79.95 Now On Sale
		SQL for IBM i: A Database Modernization Guide Learn how to use SQL’s capabilities to modernize and enhance your IBM i database. List Price $79.95 Now On Sale

Also Read

RPG Academy - Database Modernization: A Bit of Database Theory

Talking About Modernization Isn’t Good Enough

Why ERP Migrations Fail