Barker's Notation Erd Symbols and Meanings Explained

If you've ever opened an entity-relationship diagram and felt lost trying to read the shapes and lines, you're not alone. Barker's notation ERD symbols are used by database designers, business analysts, and data modelers to show how data entities connect in a system. Understanding these symbols means you can read and create clear data models that development teams, stakeholders, and databases actually follow. This article breaks down every Barker's notation symbol, what each one means, and how to use them correctly.

What Is Barker's Notation and Where Did It Come From?

Barker's notation is a method for drawing entity-relationship diagrams (ERDs) that was developed by Richard Barker in the 1980s while working at Oracle Corporation. It became widely adopted through Oracle's CASE (Computer-Aided Software Engineering) tools and is sometimes called Oracle notation because of that history.

The notation uses a specific set of shapes, lines, and marks to show entities, attributes, relationships, and cardinality. It was designed to be readable by both technical and non-technical people a diagram that a business analyst and a database developer could both understand without translation.

Unlike some notations that focus heavily on theoretical completeness, Barker's notation was built for practical database design. It leans toward the relational model, meaning the diagrams translate fairly directly into relational database tables.

What Do the Entity Symbols Look Like in Barker's Notation?

An entity in Barker's notation is drawn as a rounded rectangle a box with soft, rounded corners. Inside the box, you'll find:

Entity name at the top, written in uppercase and singular (e.g., CUSTOMER, ORDER, PRODUCT)
A horizontal line separating the name from the attributes below
Attributes listed below the line

Each attribute can have specific markers:

A hash symbol (#) before an attribute means it is part of the primary key the unique identifier for that entity.
A asterisk () before an attribute means the attribute is mandatory it must have a value.
A circle (o) before an attribute means it is optional it can be left empty or null.

So if you see # CUSTOMER_ID inside an entity box, the hash tells you it's the primary key, and the asterisk confirms it's required. This combination of markers is one of Barker's notation's strengths it packs useful information into a compact format.

What About Subtypes and Supertypes?

Barker's notation handles entity subtyping with a specific symbol. A supertype entity connects to a circle, and lines branch out from that circle to each subtype entity. Each branch line can be marked as mandatory or optional, showing whether an instance of the supertype must belong to at least one subtype.

For example, a PERSON supertype might branch into EMPLOYEE and CUSTOMER subtypes. The circle between them acts as a discriminator, and the notation lets you indicate whether every person must be classified or if some people exist in the system without a subtype role.

How Does Barker's Notation Show Relationships and Cardinality?

Relationships are where Barker's notation really stands out. A relationship is drawn as a solid line between two entities, with cardinality markers at each end of the line. These markers tell you how many instances of one entity can be associated with another.

The cardinality symbols at the ends of relationship lines work like this:

A solid dot (●) or filled circle means "one and only one" (exactly one) this is mandatory one.
An empty circle (○) means "zero or one" this is optional one.
A crow's foot or "many" marker (three prongs, like a bird's foot) means "one or more" mandatory many.
A crow's foot combined with an empty circle means "zero or more" optional many.

These markers sit at the "near" end of the relationship line the end closest to the entity they describe. So if you're looking at an ORDER entity connected to a CUSTOMER entity, the marker near ORDER tells you about orders from the customer's perspective, and the marker near CUSTOMER tells you about customers from the order's perspective.

What Does a Relationship Line With Role Names Mean?

Barker's notation allows role names to be written along the relationship line. A role name describes the nature of the relationship from a specific entity's perspective. For example, between a PERSON entity and itself (a recursive relationship), you might see a role name like "manager" and "subordinate" on each end of the line.

This is useful for self-referencing relationships or any case where the relationship needs a label to make sense to readers who aren't deeply familiar with the data model.

How Is Barker's Notation Different From Other ERD Notations?

If you're comparing ERD notations, here's how Barker's stacks up against the other common styles:

The crow's foot notation shares some similarities with Barker's both use the crow's foot symbol for "many" cardinality. But crow's foot notation tends to use a more flexible set of line styles and doesn't include the same mandatory/optional attribute markers inside entities.

Chen's notation takes a very different approach. It uses diamonds for relationships, ovals for attributes, and rectangles for entities. Chen's style is more academic and works well for teaching conceptual modeling, but it can produce diagrams that are harder to read when there are many entities.

Martin (or IE) notation is another alternative that uses different shapes for cardinality. Martin notation is common in Information Engineering methodology and is seen frequently in tools like ERwin.

Barker's notation sits in a practical middle ground detailed enough for real database design, readable enough for business discussions. It was designed for the relational data modeling workflow, so it maps closely to how tables, foreign keys, and constraints actually work in a database.

When Should You Use Barker's Notation?

Barker's notation works well in several situations:

When your team uses Oracle tools many Oracle-based modeling tools default to or support Barker's notation natively.
When you need both business and technical readers the notation is readable enough for stakeholders while being precise enough for developers.
When you're designing relational databases Barker's notation maps cleanly to tables, primary keys, foreign keys, and NOT NULL constraints.
When you want compact attribute detail the mandatory/optional/primary key markers inside entities save space and reduce the need for separate documentation.

What Does a Real Barker's Notation ERD Look Like?

Here's a practical example. Say you're modeling a simple order system with three entities: CUSTOMER, ORDER, and ORDER_LINE.

CUSTOMER entity: primary key #CUSTOMER_ID, mandatory NAME, optional oPHONE
ORDER entity: primary key #ORDER_ID, mandatory ORDER_DATE, optional oNOTES
ORDER_LINE entity: primary key #LINE_ID, mandatory QUANTITY, mandatory UNIT_PRICE

Relationships would be:

CUSTOMER to ORDER: A customer can place zero or more orders (empty circle + crow's foot on the ORDER end). An order must belong to exactly one customer (solid dot on the CUSTOMER end).
ORDER to ORDER_LINE: An order must have one or more line items (solid dot + crow's foot on ORDER_LINE end). Each line item belongs to exactly one order.

Reading the diagram, you immediately know that every order needs a customer, but a customer can exist in the system without any orders yet. That kind of clarity is exactly what Barker's notation provides.

What Mistakes Do People Make With Barker's Notation?

Several common errors trip up people who are new to this notation:

Confusing the direction of cardinality markers the marker near an entity describes that entity's participation, not the other entity's. Swapping them reverses the meaning entirely.
Forgetting to mark mandatory attributes if an attribute must have a value, the asterisk is required. Omitting it makes the model ambiguous and can lead to missing NOT NULL constraints in the actual database.
Using plural entity names Barker's notation convention uses singular names (ORDER, not ORDERS). Plural names cause confusion when reading relationship sentences like "each CUSTOMER places zero or more ORDER."
Overloading the diagram putting every single attribute on a diagram with 30+ entities makes the ERD unreadable. Barker's notation supports showing only key attributes at the conceptual level and deferring others to the physical model.
Mixing notations combining Barker's symbols with Chen's diamonds or Martin's different cardinality markers creates diagrams that nobody can read consistently.

How Can You Get Better at Reading and Drawing Barker's ERDs?

Practice reading them out loud as sentences "Each CUSTOMER may place one or more ORDERs" or "Each ORDER must contain one or more ORDER_LINEs." If the sentence makes sense, the diagram is probably right.
Start with just entities and relationships draw the boxes and lines first, add cardinality markers second, then fill in attributes last. Trying to do everything at once leads to messy diagrams.
Use a tool that supports Barker's notation tools like Oracle SQL Developer Data Modeler, Lucidchart, or draw.io can help you create clean diagrams without hand-drawing symbols.
Compare your diagram to real SQL once you've drawn the ERD, try writing the CREATE TABLE statements. If you can't map the diagram to SQL cleanly, there's probably an issue with the model.

Quick Checklist for Working With Barker's Notation

Entity names are singular and uppercase
Primary key attributes marked with #
Mandatory attributes marked with
Optional attributes marked with o
Cardinality markers placed at the correct (near) end of each relationship line
Solid dot used for "exactly one," empty circle for "zero or one"
Crow's foot used for "many," combined with circle for "zero or more"
Role names added where relationships are ambiguous
Subtype/supertype hierarchies shown with circle connectors
Diagram reads correctly as natural-language sentences

Next step: Take a small part of your current project maybe three to five entities and draw it in Barker's notation. Read each relationship as a sentence. If the sentences make sense to someone who doesn't know your system, the diagram is doing its job.