ER Diagram (Entity-Relationship Diagram): What It Is and How to Build One

An entity-relationship diagram (ER diagram) is how database designers plan the structure of a database before they build it for real. GeeksforGeeks describes the ER model as “a conceptual model for designing a database”: a layer of reasoning upstream of the tables, where you decide what to track and how it connects, not yet how it’s physically stored.

An ER diagram isn’t an algorithm that solves a problem step by step, but the reasoning behind it is similar: it breaks a complex domain down — thought through in the abstract, the way an algorithm does — into smaller, connected pieces. Sites built in JavaScript or PHP, behind the scenes, also sit on a database that was planned upstream with a diagram of exactly this kind. For a broader look at what a database is and the types that exist, the Recap on database management systems is the place to start; this Recap zooms in on the technique for designing one before writing it.

The Three Basic Building Blocks

An ER diagram is built from three elements. Visual Paradigm defines an entity as “a definable thing or concept within a system” — a person or role (for example a Student), an object (an Invoice), a concept (a Profile) or an event (a Transaction). GeeksforGeeks gives a concrete example: Student, Course or Company are entities.

An attribute, per Visual Paradigm, is “a property or characteristic” of the entity that holds it: GeeksforGeeks points to StudentID, CourseName or EmployeeEmail as examples. And a relationship, finally, is the connection that shows two entities are associated with each other — the simplest example, again from GeeksforGeeks, is “Student enrolls in a Course.”

Cardinality: How Many Instances Connect

Defining entities, attributes and relationships isn’t enough: you also need to say how many instances of one entity connect to how many instances of the other. That’s cardinality, which Visual Paradigm describes as the number of possible occurrences of one entity associated with the number of occurrences of another.

GeeksforGeeks offers three minimal examples, one for each cardinality type:

Type	Example	Meaning
One-to-one (1:1)	Person and passport	One person holds one passport, and one passport belongs to one person
One-to-many (1:N)	Department and doctors	A department can have several doctors, but each doctor belongs to one department
Many-to-many (N:M)	Employees and projects	An employee works on several projects, and a project has several employees

The database design textbook by Watt and Eng adds a practical note: a one-to-many relationship “should be the norm in any relational database design,” meaning it’s the most common type in relational databases. The same source also notes that a many-to-many relationship “cannot be implemented as such in the relational model”: it doesn’t translate directly into a single table, and needs an extra step during conversion into the actual database.

The Two Notations: Chen and Crow’s Foot

Standard symbols exist for drawing entities, attributes, relationships and cardinality, collected into two different notations.

Chen notation, according to GeeksforGeeks, uses a distinct geometric shape for each element:

Symbol	Meaning
Rectangle	Entity
Double rectangle	Weak entity
Oval	Attribute
Underlined oval	Key attribute
Double oval	Multivalued attribute
Dashed oval	Derived attribute
Diamond	Relationship

Crow’s Foot notation, explained by freeCodeCamp, represents cardinality instead with marks at the ends of the lines that connect entities:

Symbol	Meaning
Circle	Zero
Single bar	One
Crow’s foot (three lines)	Many
Circle + crow’s foot	Zero or many
Bar + crow’s foot	One or many
Two bars	One and only one

Visual Paradigm confirms the same idea from another angle: “In an ER diagram, cardinality is represented as a crow’s foot at the connector’s ends.” freeCodeCamp also gives two minimal examples: in a Teacher-Course relationship, a teacher teaches “one and only one” course, while a course is taught by “one or many” teachers; in a Customer-Pizza relationship, a customer orders “zero or many” pizzas, and a pizza is ordered by “zero or many” customers.

How to Build One: A Step-by-Step Example

Worked example: imagine sketching out part of a database for a university.

First step: identify the entities involved. Here you need a Student, a Course and an Instructor.

Second step: list the attributes of each entity. The Student has a StudentID, the Course has a CourseName.

Third step: identify the relationships between the entities. A Student enrolls in a Course. An Instructor teaches a Course — for example, as the same textbook puts it, Prof. Ba teaches the Database Systems course.

Fourth step: assign cardinality to each relationship, choosing whether to draw it with Chen or Crow’s Foot. A relationship can be one-to-one, one-to-many or many-to-many, depending on what actually happens between the two entities.

Fifth step: draw it. With Chen notation, a rectangle for each entity, an oval for each attribute connected to its rectangle, a diamond for each relationship. With Crow’s Foot, entities stay inside a box with their attributes listed inside, and it’s the lines connecting them — ending in a circle, a bar or a crow’s foot — that tell the cardinality story.

A diagram like this, with its entities, attributes and cardinality-marked relationships, is the starting point from which the actual database tables get written: for the general concepts of what a database is and how it works, the Recap on database management systems remains the place to go.