Home Think Topics Entity relationship diagram What is an entity relationship diagram?
Explore IBM OpenPages Subscribe to AI topic updates
Isometric illustration showing shapes and clouds

Published: 24 June, 2024
Contributors: Ivan Belcic, Cole Stryker

What is an entity relationship diagram?

An entity relationship diagram (ER diagram or ERD) is a visual representation of how items in a database relate to each other. ERDs are a specialized type of flowchart that conveys the relationship types between different entities within a system. They use a defined set of symbols, including rectangles, ovals and diamonds, and link them with connecting lines.

Within the relational model of database design, ERDs establish how entries in a database are connected. ERDs are a high-level conceptual data model that sets the stage for more advanced database design and analysis.

Also, entity relationship modeling can help distill narratives and insights from a seemingly disparate collection of data points.

KuppingerCole Leadership Compass on Database and Big Data Security

Get an overview of the market for database and big data security solutions along with the right sensitive data protection products to meet client requirements.

Related content

IBM Cloud® Professional Site Reliability Engineer SRE

What are ERDs used for?
      Database design and data modeling

      Business analysts and database engineers use ER diagrams as data modeling tools to assess the scope of the databases their organizations need, then plan out how the data will be stored. 

      ERDs inform the software engineering portion of a database project by laying out the requirements for the information systems architecture and database structure. In the three-schema approach to software engineering for database management systems (DBMS), the ERD is the conceptual tier. 

      Data integration is a complex data engineering process consisting of many moving parts. An ERD can help data engineers conceptualize the overall system and reduce the potential for errors. 

      Database problem-solving

      Comparing existing databases to an ERD can reveal database design missteps that might be causing problems. Complex databases with numerous tables require extensive SQL knowledge for the debugging process. An ERD summarizes the database so engineers can quickly identify potential errors. 

      Business process reengineering (BPR):

      When undertaking business process reengineering projects, it can be helpful to obtain a bird’s-eye view of all the data within an organization’s information systems. ERDs are used to draft newer, more efficient data architecture solutions that facilitate the other stages of the BPR process.

      Comparing ERDs, database schemas and data flow diagrams

      Entity relationship diagrams, database schemas and data flow diagrams all visually represent the way data is arranged in a system.

      • Entity relationship diagrams illustrate the entities within a database and their relationships to each other. ER diagrams often depict database schemas.

      • Database schemas establish how real-world entities will be modeled in a relational database. They contain the rules and guidelines that determine the organization of the database, such as table names, fields and data types.

      • Data flow diagrams are a type of flowchart that depicts the flow of data through a process or system. They show how data moves from process to internal and external storage locations.

      Common ERD components

      Entity relationship diagrams include entities, the attributes of those entities and the relationships between them. Some ERDs also convey cardinality, which quantifies the relationship between two entities.


      An ERD entity is a definable thing, such as a person, role, event, concept or object, that can have information about it stored in a relational database. Many styles of entity relationship diagrams depict entities as rectangles.

      • People or roles: Students, salespeople, executives or customers.
      • Events: Transactions, signups or unsubscribes.
      • Concepts: Profiles or personas.
      • Objects: Products, invoices or emails.

      Entities are similar to nouns in a grammatical sense. They are core items in the database, with attributes and relationships conveying information about these entities, just as adjectives and verbs provide more information about the nouns in a sentence.

      Entity types

      Entity types are a category of entities. If entities are similar to nouns, then entity types are noun categories: foods, sports and countries. The individual entities within an entity type are known as instances. Within the entity type, vegetables might be the instances broccoli, carrot and asparagus.

      Strong entities versus weak entities

      Entities are classified as either strong or weak. Strong entities contain enough identifying information in their attributes to not need further clarification. Meanwhile, weak entities exist only as an outcome or consequence of another entity. The strong entity associated with a given weak entity is known as its parent or owner entity.

      Consider a database modeling customer order in an e-commerce business. Each order is a strong entity because it can be defined as a unique instance based on the purchaser, time and date. However, the line items within each order are weak entities. They only have meaning within the context of their respective orders. This reliance is known as existence dependency or participation constraint.

      Strong entities are shown as solid rectangles, while ERDs represent weak entities as a double rectangle.

      Associative entities

      An associative entity links the instances between two entity sets and has its own attributes that provide more information about that relationship. In an ERD used by a university, the entity sets students and professors to have many connections to each other. The associative entity bridging the two would show which students are taking courses taught by which professors.

      Relational databases use associative entities to inform junction tables, which combine fields from multiple other database tables. In ER diagrams, associative entities are depicted as a diamond within a rectangle.


      Attributes are qualities, properties and characteristics that define an entity or entity type. In a classic ERD design, attributes are shown as ovals and are displayed next to the corresponding entity in an ERD. 

      Types of attributes
      • Simple attributes cannot be simplified or split up into further attributes. A ZIP code is an example of a simple attribute.
      • Composite attributes are compiled from other attributes, which might or might not be simple. An address is a composite attribute containing a street number, street name, ZIP code, city and other identifying information.
      • Derived attributes are calculated based on other attributes. An employee’s paycheck value is derived from their hours worked, the duration of the pay period, and their wage. ERDs depict derived attributes as dashed ovals.
      • Multivalue attributes can have more than one value per record, while a single-value attribute cannot.
      Key attributes

      Entity keys are the attributes that uniquely define each entity in a data set. Any attribute can be designated as a key, provided that it fills this role. For example, in a people entity set, an appropriate key attribute might be a national ID number. Conversely, surnames would not work as a key attribute in this context since more than one person can share the same surname. 

      • Super key: One or more attributes that can uniquely define an entity within an entity set.
      • Candidate key: The simplest possible super key—no attributes within a candidate key can be a super key in itself. Candidate keys might consist of one or more attributes if each attribute is not a super key. 
      • Primary key: The candidate key is chosen to uniquely define an entity set. Since the primary key is what sets each entity apart, no two entries in a database might share the same primary key value. In an ER diagram, each entity’s primary key will be underlined. Any entity containing a primary key is considered a strong entity. 
      • Foreign key: An attribute that identifies one entity’s relationship to another. Weak entities rely on foreign keys to define them as strong entities. For example, the weak entity bank account would need a foreign key linking it to the relevant bank. 

      Relationships are the connected lines linking the entities in an ERD together. They indicate how entities within an ERD are associated with each other. If entities are nouns, and attributes are adjectives, then relationships are verbs.

      In a traditional ERD, relationships are depicted as diamonds. Weak relationships bind a weak entity with its owner and are shown as double diamonds.

      Entity participation in a relationship might be total, in which case the entirety of the entity set is involved in the relationship or partial. In partial participation, some or all of the entities within the set might be involved in the relationship at any specific time.

      Relationship cardinality

      Cardinality is the quality of a relationship that defines the number of instances in one entity that relate to the instances of another.

      • One-to-one relationships (1:1) indicate that a record within one entity might only be referenced by one record in the other entity. The relationship between the entities' universities and presidents is a one-to-one relationship because every university has only one president. Conversely, each president is responsible for exactly one university.
      • One-to-many relationships (1:M) depict situations in which each record within one entity relates to multiple records in another entity. There is a one-to-many relationship between the entities universities and departments. A university might have multiple departments, but each department is part of just one university.
      • Many-to-many relationships (M:M) show that one or more records within both entities can be connected. The entities students and professors have a many-to-many relationship because just as one professor teaches a class with many students, each student might also enroll in classes with other professors.

      ERDs represent cardinality through variations in the connecting lines between entities. The way cardinality is shown depends on the style of ERD used.

      Types of ER models

      Most ERDs are drafted in one of three entity-relationship models: conceptual, logical and physical. All three depict entities along with their attributes and relationships, but their use cases and intended audiences differ. Conceptual is the least detailed, while physical ERDs offer the most granular information.

      • Conceptual ER models offer a high-level view of the data within the ERD. Business analysts use them for large-scale database design projects such as data warehouses. Conceptual data models usually contain entities and relationships while diving no deeper into database tables and cardinality.
      • Logical ER models are similar to conceptual models, but with slightly more detail. In a logical data model, the columns or attributes within each entity are defined, as are operational and transactional entities. Business analysts use logical data models for smaller-scale database design projects.
      • Physical ER models are the concrete blueprints for database design projects. They include the maximum amount of detail, such as cardinality and primary and foreign keys. Database designers and engineers create physical data models from the conceptual and logical models given to them by business analysts.
      ERD styles

      Since computer scientist and database theorist Peter Chen introduced ERDs in the 1970s, multiple types of diagrams have emerged to fill an increasing range of use cases.

      Chen style

      Chen ERDs look similar to classical flowcharts, with various shapes connected by lines. Cardinality is shown with the characters 1, M and N along the connecting lines. M and N both represent “many” in a one-to-many or many-to-many relationship; depicting the latter with M:N or N:M notation implies that the number of entities in the relationship need not be equal on both sides.

      The Chen style depicts total participation with a single connecting line and partial with a double connecting line.

      Crow’s foot notation

      Named for its three-pronged forked connecting line showing many relationships, crow’s foot notation replaces Chen’s symbols with tables. Each table represents an entity and contains all its attributes. Crow’s foot notation allows ERD creators to show information regarding relationship cardinality.

      Bachman style

      Charles Bachman’s data structure diagrams directly inspired Chen in the creation of the ERD. Bachman used lines with arrows to indicate cardinality in relationships.

      IDEF1X style

      The US Air Force introduced its Integration DEFinition for information modeling (IDEF1X) language in the 1980s to support the development of semantic data models. It took Chen’s work a step forward by displaying attributes within a shared table and introducing more options for cardinality.

      Barker style

      Created by Richard Barker in 1981, the Barker style is the standard for use in Oracle. Barker notation shares the crow’s foot style for connecting lines while also using dashed lines to represent partial or optional participation.

      Related products and solutions
      IBM® OpenPages®

      IBM OpenPages is an AI-driven, highly scalable governance, risk and compliance (GRC) solution that runs on any cloud with IBM Cloud Pak® for Data.

      Explore OpenPages

      IBM® Db2®

      IBM Db2 is the cloud-native database built to power low-latency transactions, real-time analytics and artificial intelligence (AI) applications at scale.

      Discover Db2

      IBM Database Solutions

      Scale applications, analytics and gen AI faster with databases across the hybrid cloud.

      Explore IBM Database Solutions
      Resources Tackling AI’s data challenges with IBM databases on AWS

      Businesses face significant hurdles when preparing data for AI applications. The existence of data silos and duplication, alongside apprehensions regarding data quality, presents a multifaceted environment for organizations to manage.

      Integrating AI into Asset Performance Management: It’s all about the data

      Imagine a future where AI seamlessly collaborates with existing supply chain solutions, redefining how organizations manage their assets. If you’re currently using traditional AI, advanced analytics and intelligent automation, aren’t you already getting deep insights into asset performance?

      Take the next step

      Simplify data governance, risk management and regulatory compliance with IBM OpenPages—unified and highly scalable AI-powered software for governance, risk and compliance.

      Explore IBM OpenPages Book a live demo