If you've ever stared at a database diagram and wondered what all those lines, crow's feet, and symbols actually mean, you're not alone. IE notation short for Information Engineering notation is one of the most widely used methods for designing and documenting database schemas. Knowing its syntax helps you read existing schemas accurately, communicate database designs to your team, and avoid costly misinterpretations during development. This reference breaks down the core syntax so you can use it with confidence.

What is IE notation and why do database designers use it?

IE notation is a graphical method for representing entity-relationship (ER) diagrams. It was developed as part of the Information Engineering methodology in the 1970s and 1980s, primarily by Clive Finkelstein and James Martin. Unlike Chen notation, which uses diamonds to represent relationships, IE notation places relationship information directly on the connecting lines between entities. This makes diagrams more compact and easier to read at a glance, which is why many database tools and teams prefer it.

You'll encounter IE notation in tools like Microsoft Visio, ERwin, Lucidchart, and MySQL Workbench. It's the default notation in many enterprise database design environments.

What are the core syntax elements of IE notation?

IE notation relies on a small set of visual symbols. Each one communicates a specific piece of information about the database schema.

Entities

An entity is represented as a rectangle (or rounded rectangle). The entity name goes inside the box, usually in bold or uppercase. Attributes are listed below the entity name, separated by a horizontal line. Primary key attributes are typically marked with an underline, a "PK" label, or both.

• Strong entity: A standard rectangle it exists independently and has its own primary key.
• Weak entity: A rectangle with a double border it depends on another entity for identification.

Relationships

Relationships are shown as lines connecting two entity rectangles. The relationship verb or phrase (such as "places," "contains," or "belongs to") is written on or near the line. Diamond shapes are not used in IE notation that's a hallmark of Chen notation and other ER diagram styles.

Cardinality and participation

This is where IE notation gets its visual identity. Cardinality tells you how many instances of one entity can be associated with another. Participation tells you whether an association is mandatory or optional.

IE notation uses two visual layers on the relationship lines:

1. Crow's foot symbol (three-pronged fork): Indicates a "many" side one or more related records.
2. Single line (no fork): Indicates a "one" side exactly one related record.
3. Circle (○): Indicates zero the relationship is optional.
4. Dash ( ): Indicates one the relationship is mandatory (exactly one).
5. Double line or bold line: Indicates mandatory participation (at least one).

You combine these to express four common cardinality-participation pairs:

• Zero or one (0..1): A circle on the "one" end.
• Exactly one (1): A dash on the "one" end.
• Zero or many (0..): A circle plus a crow's foot.
• One or many (1..): A dash plus a crow's foot.

How do you read an IE notation diagram step by step?

Reading an IE diagram follows a consistent pattern. Pick any two connected entities, then ask these three questions:

1. What are the entities? Read the names inside the rectangles.
2. What is the relationship? Read the verb on the connecting line.
3. What are the cardinality and participation rules? Look at the symbols on each end of the line circle or dash for optional/mandatory, crow's foot for "many."

For example, if you see a Customer entity connected to an Order entity with the line labeled "places," and the Customer end has a dash (one) while the Order end has a crow's foot with a dash (one or many), you can read this as: "A customer places one or more orders. Each order belongs to exactly one customer."

What does a practical IE notation schema look like?

Here's a simple schema for an online bookstore using IE notation syntax in text form:

Author (AuthorID PK, Name, Bio) writes ▸ Book (BookID PK, Title, ISBN, Price)

Cardinality: One Author writes Zero or Many Books. Each Book is written by Exactly One Author.

In this example:

• "Author" has a dash on its end (exactly one author per book).
• "Book" has a circle plus crow's foot on its end (an author may have zero or more books).

Another example:

Student (StudentID PK, Name, Email) enrolls in ▸ Course (CourseID PK, Title, Credits)

Cardinality: One Student enrolls in Zero or Many Courses. One Course has One or Many Students.

This is a many-to-many relationship, which would typically be resolved with a junction table (like Enrollment) in the physical schema.

What are common mistakes when using IE notation?

Several errors come up repeatedly, especially for people new to database modeling:

• Confusing cardinality with participation. Cardinality (one vs. many) and participation (mandatory vs. optional) are separate concepts. A crow's foot alone doesn't tell you whether the relationship is required you need the circle or dash symbol as well.
• Mixing notation styles. Using Chen notation diamonds alongside IE crow's feet creates confusion. Stick to one notation per diagram.
• Placing the crow's foot on the wrong end. The crow's foot goes on the "many" side, next to the entity that can have multiple related records. Reversing it changes the meaning entirely.
• Skipping weak entity notation. If an entity depends on another for its primary key, use a double border. Leaving it as a regular rectangle misrepresents the dependency.
• Ignoring minimum cardinality. Only showing "one" or "many" without specifying whether the relationship is mandatory or optional leaves ambiguity for developers implementing the schema.

How does IE notation compare to other ER diagram notations?

IE notation is one of several established notations. The most common alternatives are Chen notation (which uses ovals for attributes and diamonds for relationships) and Martin/UML notation. The main difference is readability at scale. IE notation produces more compact diagrams because relationship details live on the connecting lines rather than in separate diamond shapes. For large enterprise schemas with dozens of entities, this saves significant space.

You can read a full side-by-side breakdown in this comparison of Chen notation and crow's foot ER diagrams to decide which works best for your project.

Tips for using IE notation effectively in your projects

• Label every relationship line with an active verb. "Customer places Order" is clearer than a line with no label.
• Show all four cardinality-participation symbols on both ends of each relationship. Leaving one end unlabeled forces assumptions.
• Use a legend if your audience includes people unfamiliar with IE notation. Even a small box in the corner showing each symbol and its meaning prevents confusion.
• Keep attributes minimal in conceptual diagrams. Show primary keys and a few important attributes. Full attribute lists belong in logical or physical schema diagrams.
• Version your diagrams alongside your database migrations. A schema diagram from six months ago that doesn't match the current database is worse than no diagram at all.

Quick reference: IE notation symbol cheat sheet

Symbol	Meaning	Example reading
Rectangle	Strong entity	Customer
Double-border rectangle	Weak entity	Dependent
Crow's foot (₤)	Many	Zero or many / one or many
Circle (○)	Zero (optional)	Zero or one / zero or many
Dash ( )	One (mandatory)	Exactly one / one or many
Line with text label	Relationship	"places," "contains"

For a deeper look at each symbol and how it maps to actual database constraints, see this guide on database schema notation symbols explained.

What should you do next?

Use this checklist to put IE notation into practice:

• ☐ Pick a diagramming tool that supports IE notation (Lucidchart, draw.io, MySQL Workbench, or ERwin).
• ☐ Identify all entities in your domain and decide which are strong vs. weak.
• ☐ Define relationships using active verbs on each connecting line.
• ☐ Assign cardinality (one or many) and participation (mandatory or optional) to both ends of every relationship.
• ☐ Mark primary keys on each entity with a PK label or underline.
• ☐ Add a legend if your diagram will be shared with non-specialists.
• ☐ Review the diagram with your team before generating physical schemas misread relationships are the most expensive bugs to fix late in a project.

Start by sketching one small section of your database in IE notation this week. Getting the syntax into muscle memory is faster than you think once you've drawn two or three diagrams.

Reference: The original Information Engineering methodology is documented in James Martin's Information Engineering book series (1989–1990). For a modern overview, see the Wikipedia entry on entity-relationship models, which covers IE notation alongside other approaches.