Martin Notation Erd Symbols and Their Meanings Explained

If you've ever tried to design a relational database and found yourself staring at a jumble of shapes, lines, and arrows without knowing what they mean, you're not alone. Entity-relationship diagrams are only useful when everyone on your team reads the symbols the same way. That's exactly where Martin notation comes in. Understanding Martin notation ERD symbols and their meanings gives you a consistent, widely recognized framework for mapping out databases clearly whether you're working solo or handing off a schema to a development team.

What is Martin notation in an ERD?

Martin notation, also called James Martin's ERD notation, is a specific set of symbols used in entity-relationship diagrams to represent entities, attributes, relationships, and cardinality. It was introduced by James Martin as part of his work on information engineering and database design methodology. The notation uses a combination of rectangles, ellipses, lines, and specific markers to show how data entities connect and interact within a system.

Unlike UML class diagram notation, which borrows from object-oriented design, Martin notation stays rooted in relational database thinking. That makes it a natural fit for data modelers, database architects, and analysts who need to communicate schema designs without ambiguity.

What do the core Martin notation ERD symbols mean?

Each symbol in Martin notation carries a specific meaning. Here's a breakdown of the primary symbols you'll encounter:

Entities

Entities are represented as rounded rectangles (sometimes plain rectangles depending on the variation). Each entity corresponds to a table in a relational database. The entity name goes inside the shape. For example, "Customer," "Order," or "Product" would each sit inside their own rounded rectangle.

Attributes

Attributes appear as ellipses (ovals) connected to their parent entity by a line. Each attribute represents a column or field within that entity's table. For instance, a "Customer" entity might have attributes like "CustomerID," "Name," and "Email."

The primary key attribute is typically underlined to distinguish it from regular attributes.

Relationships

Relationships are shown as lines connecting two entities. A diamond or label on the line describes the nature of the relationship (such as "places," "contains," or "belongs to"). Not all Martin notation variations use diamonds some place the relationship verb directly on the connecting line.

Cardinality and participation markers

This is where Martin notation gets specific. Cardinality is expressed through symbols at the ends of relationship lines:

"1" exactly one instance
"M" or "N" many instances (one-to-many or many-to-many)
"0" zero instances (optional participation)
A crow's foot symbol (three-pronged fork) indicates "many" on the relationship line
A single line or bar indicates "one"
A circle indicates "zero" (optional)

For example, if a "Customer" entity connects to an "Order" entity with a "1" on the Customer side and a crow's foot on the Order side, it means one customer can place many orders, but each order belongs to exactly one customer.

How does Martin notation compare to other ERD notations?

Martin notation is one of several competing standards for ERD diagrams. If you're choosing between notations, it helps to know where it stands. For a deeper comparison, this breakdown of ERD notation codes for database architects covers multiple systems side by side.

Here's a quick summary of how Martin notation differs from the most common alternatives:

Chen notation uses diamonds for all relationships and doesn't employ crow's foot symbols. It tends to be more verbose and academic.
Crow's foot (Martin) notation is more compact and widely used in commercial database design tools like Microsoft Visio and Lucidchart.
UML notation maps relationships using multiplicity expressions and class diagram conventions, which work better for object-oriented systems than pure relational schemas.

Martin notation strikes a balance. It's detailed enough to communicate cardinality and participation constraints clearly, but not so complex that it slows down the modeling process.

When should you use Martin notation?

Martin notation works best when you're designing relational databases and need a diagramming style that most database professionals will recognize without a legend. Common situations include:

Presenting schema designs to stakeholders who need to understand data relationships without reading SQL
Documenting existing databases for onboarding new team members
Planning database migrations where mapping entity relationships is a required step
Communicating with teams that use commercial ERD tools (most tools default to crow's foot / Martin-style notation)

If your team already works with UML-heavy documentation or object-oriented models, you might find it easier to compare UML class diagram notation to traditional ERD notation before committing to one style.

What does a practical Martin notation ERD look like?

Let's walk through a simple example: a library database.

Entities: Member, Book, Loan

Attributes for Member: MemberID (primary key, underlined), FullName, Email, JoinDate

Attributes for Book: ISBN (primary key), Title, Author, AvailableCopies

Attributes for Loan: LoanID (primary key), LoanDate, DueDate, ReturnDate

Relationships:

Member to Loan: One member can have many loans (1:M). A single line on the Member side, a crow's foot on the Loan side.
Book to Loan: One book can appear in many loans over time (1:M). Same cardinality pattern.

The diagram would show Member connected to Loan with the label "borrows," and Book connected to Loan with the label "is borrowed." Each attribute hangs off its entity as an oval. The primary keys are underlined.

This kind of diagram gives a developer everything they need to write the CREATE TABLE statements with proper foreign key relationships.

What are the most common mistakes when reading Martin notation?

Even experienced developers sometimes misread ERD symbols. Here are the errors that come up most often:

Confusing "one" and "many" markers. The crow's foot always means "many." If you see a single line with no additional marker, assume "one." A circle next to the crow's foot means "zero or many."
Ignoring participation constraints. A straight line (mandatory) means every instance must participate. A circle (optional) means participation isn't required. Skipping this distinction leads to incorrect NOT NULL decisions in your schema.
Assuming all Martin notation variations are identical. Different tools render the symbols slightly differently. Always check the legend if you're reading a diagram from an unfamiliar tool.
Confusing attributes with entities. Attributes are ovals connected to an entity. If something looks like it could be an entity but has no relationships of its own, it's probably an attribute.
Mixing notation styles in one diagram. Combining Chen diamonds with crow's foot cardinality markers in the same diagram creates confusion. Pick one convention and stick with it.

Tips for using Martin notation effectively

Name relationships as verbs. "Customer places Order" reads better as a diagram label than "Customer-Order." Verb-based labels make the diagram self-documenting.
Always mark primary keys. Underlining the primary key attribute in each entity prevents confusion about which field uniquely identifies a record.
Use consistent cardinality placement. Place the "1" side of a relationship on the entity that acts as the parent (the side with the primary key). The "many" side goes on the child entity with the foreign key.
Keep your diagram readable. If you have more than 10-12 entities in one diagram, consider splitting it into sub-diagrams organized by module or business area.
Validate your ERD against actual queries. Walk through the queries your application will run and confirm the diagram supports every join path you'll need.

Checklist: Reviewing a Martin notation ERD

Every entity is represented as a rounded rectangle with a clear, singular noun name
All primary key attributes are underlined
Relationship lines clearly show "1" and "many" markers on the correct sides
Optional participation (circle) vs. mandatory participation (line) is marked where applicable
Relationship labels use active verbs that describe the connection
No entity is missing a primary key attribute
Many-to-many relationships are resolved through a junction/associative entity
The diagram uses one consistent notation style throughout
Foreign key attributes match the data type of the referenced primary key
Someone unfamiliar with the project can understand the diagram without oral explanation

Start by sketching your next ERD on paper using Martin notation before opening any software. Getting the symbols and relationships right on a rough draft first prevents wasted time reworking diagrams in a tool. Once the logic is sound, digitize it using a tool that supports standard ERD notation codes so your team can read and maintain it over time.