Data Modeling Diagram Symbols and Notations Guide

If you've ever stared at a database diagram and felt lost in a sea of shapes and lines, you're not alone. Data modeling diagrams use specific symbols and notations to represent how data is structured, related, and organized. Without understanding these visual elements, designing or even reading a database schema becomes guesswork. This guide breaks down the most common diagram symbols and notations so you can confidently read, create, and communicate data models whether you're working on a small project or an enterprise system.

What are data modeling diagram symbols and notations?

Data modeling diagrams are visual representations of a database structure. The symbols are the building blocks rectangles, diamonds, ovals, lines and the notations are the rules that dictate how those symbols connect and what they mean. Together, they form a shared language between database designers, developers, and business analysts.

Think of it like a map legend. Without knowing what each icon represents, the map is just shapes on paper. Data modeling symbols work the same way: a rectangle might represent an entity (like a customer or product), while a line between two shapes shows a relationship (like a customer placing an order).

There are several notation styles in use today, and each one uses slightly different symbols to represent the same concepts. The three most widely used are Chen notation, Crow's Foot notation, and UML class diagram notation.

Why does it matter which notation you use?

The notation you choose affects how clearly your diagram communicates with your team. Different industries and tools favor different standards. A team using Microsoft SQL Server might default to Crow's Foot notation for entity-relationship diagrams, while a software engineering team working in object-oriented design might prefer UML class diagrams.

Using inconsistent or incorrect symbols leads to misunderstandings. A developer might misinterpret a relationship type, leading to a flawed database implementation. Picking the right notation and using it consistently prevents costly rework down the line.

What are the basic symbols used in ER diagrams?

Entity-Relationship (ER) diagrams are the most common type of data modeling diagram. Here are the core symbols you'll encounter:

Rectangle (Entity): Represents a real-world object or concept, such as "Customer," "Order," or "Product." Each entity typically maps to a database table.
Oval (Attribute): Describes a property of an entity, like "customer_name" or "order_date." In Chen notation, attributes hang off entities as ovals. In Crow's Foot notation, attributes are usually listed inside the entity rectangle.
Diamond (Relationship): Used in Chen notation to show how two entities relate to each other. For example, a diamond labeled "places" connects the "Customer" and "Order" entities.
Lines and Connectors: Lines show associations between entities. The style of the line endpoint (crow's foot, circle, dash) indicates cardinality how many instances of one entity relate to another.
Primary Key Marker: Attributes that serve as unique identifiers are often underlined or marked with "PK" inside the entity.

If you want a deeper walkthrough of how these symbols map to relational database schemas, our guide on ER diagram codes for relational database schema covers that in more detail.

How does Crow's Foot notation differ from Chen notation?

These two notation systems represent the same concepts but look very different on screen.

Chen notation

Developed by Peter Chen in 1976, this style uses ovals for attributes, diamonds for relationships, and rectangles for entities. It's academic and thorough, which makes it popular in textbooks and university courses. The downside is that Chen diagrams can get visually cluttered on complex models.

Crow's Foot notation

Crow's Foot notation puts attributes inside the entity rectangle and uses a three-pronged symbol (resembling a crow's foot) to show the "many" side of a relationship. A single line represents "one," and the crow's foot represents "many." Circles indicate "zero," and dashes indicate "one" on the minimum side.

Here's how cardinality looks in Crow's Foot:

One-to-One (1:1): A single line on both ends of the relationship connector.
One-to-Many (1:N): A single line on one end, a crow's foot on the other.
Many-to-Many (M:N): Crow's feet on both ends. In practice, many-to-many relationships are resolved with a junction table in the physical database.

Crow's Foot is the preferred notation in most database design tools like MySQL Workbench, Microsoft Visio, and Lucidchart. Our article on Crow's Foot notation in entity-relationship diagrams provides examples and common patterns.

Where does UML fit into data modeling?

UML (Unified Modeling Language) class diagrams are common in software engineering. Instead of using ER-specific symbols, UML uses a standardized box divided into three sections: class name, attributes, and operations/methods.

In a UML class diagram used for data modeling:

The top section shows the entity (class) name.
The middle section lists attributes with their data types (e.g., customer_id : int).
The bottom section can show methods, though it's often left empty in pure data modeling.
Association lines between classes show relationships, with multiplicity markers (like "1.." for one-to-many) near each end.

UML is especially useful when your data model needs to align with application code. If your team works in object-oriented languages, UML class diagram notation explained for beginners is a solid starting point.

When should you use each type of notation?

There's no single "correct" notation it depends on your audience, project stage, and tools.

Use Chen notation when teaching or presenting conceptual models to non-technical stakeholders. The visual separation of entities, attributes, and relationships makes it easy to explain.
Use Crow's Foot notation when designing relational databases for implementation. It's compact, widely supported by tools, and directly maps to table structures.
Use UML class diagrams when your data model will feed into object-oriented application design, or when you need to show both data structure and behavior.

What are the most common mistakes people make with diagram symbols?

Even experienced modelers run into trouble. Here are the errors that come up most often:

Mixing notations in one diagram. Combining Chen ovals with Crow's Foot cardinality markers confuses everyone. Pick one system and stick with it throughout the model.
Confusing cardinality with participation. Cardinality tells you the maximum number (one or many). Participation (also called optionality) tells you the minimum whether an entity must participate or can exist without the relationship. These are separate concepts, but many diagrams blur them together.
Overcomplicating the diagram. Cramming every entity and attribute into a single view makes the diagram unreadable. Break large models into subject-area diagrams or use abstraction levels (conceptual, logical, physical).
Forgetting primary and foreign keys. Without clearly marking which attributes are primary keys (PK) and foreign keys (FK), the diagram doesn't communicate how tables actually connect.
Ignoring naming conventions. Inconsistent entity and attribute names (e.g., "CustomerID" on one entity and "cust_id" on another) cause confusion during implementation.

How can you read an existing data modeling diagram?

When handed a diagram you didn't create, follow this process:

Identify the notation style first. Look at the symbols. Are relationships shown as diamonds? That's Chen. Do you see three-pronged line endings? That's Crow's Foot. Are classes split into three sections? That's UML.
List the entities. These are the rectangles (or class boxes) in the diagram. Each one represents a table or object.
Read the relationships. Follow the lines between entities and note the labels. Look at the cardinality markers to understand how many records on each side participate.
Check the attributes. Note which attributes are primary keys, which are foreign keys, and what data types are used (if specified).
Look for weak entities. In some notations, entities that depend on another entity for identification are shown with a double-bordered rectangle. These don't have their own primary key and rely on a foreign key plus a partial key.

What practical tips help when creating your own diagrams?

After years of working with data models, a few habits consistently lead to better results:

Start with a conceptual model before jumping into physical database design. Sketch out the main entities and relationships without worrying about data types or indexes.
Name entities as singular nouns. Use "Order" instead of "Orders." Singular names map more cleanly to table and class names in code.
Be consistent with abbreviations. If you abbreviate "description" as "desc" in one place, do it everywhere. Create a short glossary if needed.
Use tools with built-in notation support. Tools like dbdiagram.io, Lucidchart, Draw.io, and MySQL Workbench enforce notation rules and reduce manual errors.
Review your diagram with someone who will implement it. A model that looks clean on paper might raise questions when a developer tries to build it. Early feedback prevents surprises.

Quick reference: symbol comparison across notations

Here's a side-by-side summary of how each notation handles the same concepts:

Entity/Class: Chen uses a single-border rectangle. Crow's Foot uses a rectangle with attributes listed inside. UML uses a three-section box.
Attribute: Chen uses an oval connected to the entity. Crow's Foot lists attributes as text inside the entity box. UML lists attributes in the middle section of the class box.
Relationship: Chen uses a diamond shape. Crow's Foot uses a labeled line between entities. UML uses a labeled association line.
Primary Key: Chen typically underlines the attribute. Crow's Foot marks it with "PK" or underlines it. UML marks it with a stereotype or prefixes it.
Cardinality "Many": Chen shows "N" or "M" near the relationship diamond. Crow's Foot uses the three-pronged (crow's foot) symbol. UML uses multiplicity expressions like "" or "0..".

What should you do next?

If you're ready to put these symbols into practice, start by picking one notation and designing a simple model for a real scenario like a library checkout system or an online store. Keep it to three or four entities at first. Once you're comfortable reading and drawing in one notation, learning the others becomes much faster.

For a practical starting point, compare how a basic schema looks in ER diagram code form versus how it would appear in UML class diagram notation. Seeing the same model rendered in different styles builds intuition quickly.

Checklist before you share your next diagram: