Growing & Complex Businesses en_US Entity Relationship Diagrams enable you to communicate and codify the relationships and rules that govern your order management system. Eliminate customer disappointment with entity relationship diagrams
Growing & Complex Businesses

Eliminate customer disappointment with entity relationship diagrams

Have you ever received an order that wasn’t yours—perhaps something you purchased online? It happens more than you may think. According to the Pitney Bowes Ecommerce Study, 56% of US consumers were disappointed with their online holiday shopping experience in 2018. Reasons included:

  • Late shipments
  • Lost items
  • Inaccurate tracking
  • Wrong order items
  • Poor packaging

An order management process is composed of a lot of moving parts with numerous hand-offs that must be executed before the right order arrives to the right customer. In the case of an online purchase, the entities involved include the following:

  • The customer
  • The customer’s order
  • The items in the order
  • An order fulfillment team
  • A picking and packing team
  • A delivery team

To avoid the types of mix-ups that leave your customers disappointed and unlikely to return to your shop, it’s important to have purpose and structure supporting your order management system.

To isolate order management inputs, define relationships among entities, and standardize processes, business leaders use activity diagrams and entity relationship diagrams (ERDs) to set up their order management systems so they can:

  • Isolate order management inputs
  • Define relationships among people, objects, places, and events
  • Standardize processes

This article will focus on explaining some basics of entity relationship diagrams and the value they bring to the order management process, and ultimately, a smooth experience for your end customer.

What are entity-relationship diagrams?

Entity-relationship diagrams are graphical representations that depict real-world data processes in terms of the relationships among people, objects, places, or events. In an order management system, an ERD can help to define the rules and relationships between the customer, their order, order items, payment, etc. so that the right parts get to the right places.

Not only are these diagrams a useful conceptual and communication tool, but they also serve as the visual starting point for developers to build your order management database. They can also be used as a reference point for re-engineering or debugging your information system after it’s built.

There are three types of entity-relationship diagrams: conceptual, logical, and physical.

A conceptual ERD is a simple object-based representation of the entities and relationships in a system, while a logical ERD is a more detailed chart-based representation of the system that shows the actual tables that will exist in the database. A physical ERD is a more advanced graphical model that shows how data should be structured in the database.

An entity-relationship diagram can be composed of up to 5 components:

  • Entities are definable things or concepts that play a role in a system. In an ERD, entities are usually nouns like customer, invoice, product, or event. The entity may take the form of a table or object.
  • Attributes are properties or characteristics of entities. Attributes of the customer entity could include name, address, account number, etc.
  • Relationships show the nature of the association between two entities.
  • Actions show how entities share information in a database
  • Connecting lines show not only the direction of relationships but also the rules of that relationship, known as cardinality (more on this later).

In this article, we will limit our discussion to entities, attributes, relationships, and connecting lines as we will not discuss physical ERDs.

This diagram depicts 6 entities:

  • The website
  • The customer
  • The order
  • Items
  • Order code
  • Order transactions

We can see that the customer attributes include customer name, address, and number. The relationship between the customer and the order is that the customer places the order, the order has an order code, and so on. This shows the basic function and entities involved in the order management system so that your company can be sure to stay focused on stakeholders and the parts of the system that bring value to them.

The next step towards building out the order management system is a logical ERD. The logical ERD will show which information should be stored in the database and the rules (or cardinality) of entity relationships.

Logical ERD for an ordering system

Below is an example of a basic conceptual ERD for an order management process.

In the logical ERD above, we can see four entities: the customer, the order, the order line items, and the product. You can also see the connecting lines between the entities that show the cardinality of the relationship.

The cardinality defines the maximum or minimum number of relational occurrences between entities. For example, a customer can have only one account number, but one customer can have many orders.


The three types of cardinality are one-to-one, one-to-many, and many-to-many.


In a logical ERD, a one-to-one cardinality is shown with a line with two tick marks, as depicted below. An example is a customer account that can only be associated with one email address, while one email address can only be associated with one (not multiple) customer accounts.

Sometimes, the one-to-one cardinality line is drawn with two tick marks to indicate both the maximum and a minimum number of possible occurrences. The below cardinality line emphasizes the relationship is at least one instance, AND at most one instance.

Sometimes, the one-to-one cardinality line is drawn with two tick marks to indicate both the maximum and a minimum number of possible occurrences. The below cardinality line emphasizes the relationship is at least one instance, AND at most one instance. 


An example of a one-to-many relationship would be an order that must have at least one order line item, but can have up to many order line items. “Many” is shown with crows feet—the relationship of one order to many order items would be shown with the following cardinality line:

You can find this cardinality line in the logical ERD above, showing that one order must have at least one but up to many line items, while each line item must correspond to at least one and only one order.

Another type of one-to-many relationship includes the possibility of zero occurrences. For example, a product item that your store has available may or may not be purchased by a customer, but the product information is still stored in your database regardless. The “zero” value is shown with a circle.

In the chart above you can see this cardinality line:

This indicates that one order line item must be associated with at least one and at most one product. In the other direction, one product may be on many product line items, but also zero order line items if no one has purchased it.


Many-to-many relationships are usually reserved for physical ERDs as they are most relevant to database design. An example would be an order table that contains many orders, each of which must be associated with at least one product, but up to many products. In the other direction, the product table contains many individual products, each of which may be part of zero or many different orders.

Without the proper cardinality relationships, your order management system would be prone with errors and it would be impossible to keep track of which customer order which items, where orders should be sent, and numerous other faults.

What’s an activity diagram?

As the name suggests, an entity-relationship diagram shows the nature of relationships in a system. Likewise, an activity diagram is more about the activities that take place in the system and the order in which they must occur.

The process begins when the order is requested, and the order is accepted and filled when all of the required information is received. Using activity diagrams relays these important subtleties and helps you build a system to deliver the service level you have promised to customers.

Avoid mistakes in your order management process

When it comes to fulfilling orders of various size, weight, and item numbers, having a predetermined logic for picking, packing, and shipping is extremely important. What if your warehouse personnel had to independently determine shipping best practices for each individual order?

Although ERDs can be a little tricky, a basic understanding of these diagrams enables you to communicate and codify the relationships and rules that govern your order management system. Similarly, activity diagrams are used to demonstrate the order in which actions must occur and bring clarity to the process. These tools can be further used as maps to build the database that will bring your order management software to life.

The good news is, you don’t necessarily need to build your own order management system from scratch. There are numerous options for business-ready, customizable order management software solutions. These enterprise grade solutions may include functions for order fulfillment, processing, tracking, inventory management, invoicing, and more.

A properly functioning order management software that matches the right items and orders to the right delivery processes saves your business time and money, and keeps your customers coming back.

This content is for information purposes only and should not be considered legal, accounting or tax advice, or a substitute for obtaining such advice specific to your business. Additional information and exceptions may apply. Applicable laws may vary by state or locality. No assurance is given that the information is comprehensive in its coverage or that it is suitable in dealing with a customer’s particular situation. Intuit Inc. does not have any responsibility for updating or revising any information presented herein. Accordingly, the information provided should not be relied upon as a substitute for independent research. Intuit Inc. does not warrant that the material contained herein will continue to be accurate nor that it is completely free of errors when published. Readers should verify statements before relying on them.

We provide third-party links as a convenience and for informational purposes only. Intuit does not endorse or approve these products and services, or the opinions of these corporations or organizations or individuals. Intuit accepts no responsibility for the accuracy, legality, or content on these sites.

Rate This Article

This article currently has 3 ratings with an average of 2.3 stars