Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
An entity-relationship diagram (ERD) is a visual model of data: it shows the things a system stores information about, the facts recorded about them, and how those things relate. It can describe a system before a database exists or show a more implementation-specific database structure. To read one accurately, identify its notation first—symbols and conventions are not universal.
What an ER diagram shows
An ERD makes a data model visible so people can reason about an information system or database before building it, while changing it, or when documenting it. Its three core components are entities, attributes, and relationships.
- Entity: A significant thing or concept about which the system needs information, such as a customer, order, place, or event. Entities are commonly drawn as boxes and often correspond to tables or objects, depending on the model.
- Attribute: A fact or property that describes an entity. In a relational database, attributes commonly map to columns. A key may be one attribute or a combination of attributes used to identify a record.
- Relationship: An association between entities. Relationship names often read like verbs, but labels and visual conventions depend on the notation.
These concepts are the model’s building blocks; their exact mapping to a working database depends on how detailed the diagram is.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →How to read Crow’s Foot symbols
Crow’s Foot is one common ERD notation. At a relationship’s endpoint, a ring means zero, a bar means one, and a three-pronged crow’s foot means many. Read the paired marks together: they express the minimum and maximum number of related instances, so optionality and cardinality are related but distinct ideas.
#1 Best Overall
| Endpoint marks | Meaning | Plain-language reading |
|---|---|---|
| Ring + bar | Zero or one | Optional; at most one |
| Bar + bar | One and only one | Required; exactly one |
| Ring + crow’s foot | Zero or many | Optional; none or multiple |
| Bar + crow’s foot | One or many | Required; at least one |
These readings apply to Crow’s Foot, not every ERD style. Other notations can use different shapes or label placement. Microsoft documents the ring/bar/crow’s-foot meanings in its Crow’s Foot database notation guide; Salesforce also explains that notation conventions vary and distinguishes cardinality from optionality in its ERD notation overview.
Example: customers and orders
Suppose a system models Customer and Order. One customer may place many orders, and each order belongs to one customer. The crow’s-foot end sits by Order; the one end sits by Customer. Whether a customer must already have an order is a separate business rule: a customer record might be allowed to exist before any purchase. The diagram should express the rule the system intends to enforce, not just connect two boxes.
Logical and physical ERDs are not the same thing
A conceptual or logical ERD communicates the functional data structure without necessarily committing to a specific database implementation. It may omit data types and implementation-level constraints. A physical diagram is closer to an actual database and may show tables, columns, primary and foreign keys, indexes, constraints, and enforced relationships.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
A primary key (PK) identifies a row, using one field or a combination of fields. A foreign key (FK) references records in another table and helps express a connection between tables. A diagram can therefore be useful without being a literal picture of the deployed database: first check whether it is conceptual, logical, or physical. Salesforce distinguishes its logical ERDs from a precise physical data model in its notation documentation, and Mermaid describes diagrams ranging from abstract logical models to physical relational models in its ER diagram guide.
Rank #3
Choosing an ERD tool for the job
Choose based on whether you are modeling a new domain or examining an existing database, how much physical detail you need, and whether you prefer visual editing or text-based authoring. The following are documented capabilities, not a comparative performance ranking.
| Tool | Best fit | Documented capability |
|---|---|---|
| Microsoft Visio | Visual diagram creation | Microsoft documents ERD templates and stencils, including support for multiple notations such as Crow’s Foot. See Visio ERD guidance. |
| SQL Server Database Designer | Working with a connected SQL Server or Azure SQL database | Microsoft documents creating, editing, and visualizing tables, columns, keys, indexes, relationships, and constraints. Relationship endpoints can indicate one-to-one and one-to-many relationships, and line style communicates referential-integrity behavior in the tool. See Database diagrams documentation. |
| Mermaid | Diagrams authored as text alongside documentation or code | Its ER syntax uses Crow’s Foot conventions and can describe conceptual through physical models. See the Mermaid ER diagram guide. |
| pgAdmin ERD tool | Viewing a graphical representation of database structure | Its pgAdmin 4 version 9.2 documentation describes a tool for representing tables, columns, and their inter-relationships. See the pgAdmin ERD Tool documentation; the cited page is version-specific. |
Before choosing, check that the tool supports the detail and relationship rules your model needs, works with your database when relevant, and fits your documentation workflow.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What an ERD does—and does not—tell you
An ERD helps clarify which data the system needs and how records are associated. It can expose questions that need a business decision, such as whether a relationship is mandatory or whether an entity can exist without a related record. It is a model, however, not proof that a database implements every rule shown. A logical diagram may intentionally leave implementation details out; a physical diagram may include them.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsWhen reviewing a diagram, confirm its notation and modeling level, then read each relationship’s endpoints as minimum and maximum participation. That prevents a common misreading: “many” alone does not say whether zero related records are allowed.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
