Choosing an ER Notation Your Team Can Read
For database architects who hand ER diagrams to developers, reviewers and stakeholders; the symbols themselves are covered in the ERD guide linked below.
On this page
In short
Pick the ER diagram notation by who has to read the diagram. Crow's foot suits most technical readers, IDEF1X suits governance reviews, and UML suits software teams. The notation is a display setting, so one model can be shown in another notation without redrawing it.
Table of contents
- Chen notation and what it is good for
- Crow's foot and Information Engineering
- Barker, IDEF1X and UML class diagrams
- Choosing by who has to read the diagram
- Where each notation stops working
- Settling on one notation for your model
- Frequently asked questions
- Sources
Key takeaways
- Chen teaches the concepts well, but its attribute shapes crowd out a real schema.
- Crow's foot shows cardinality and optionality at the line ends, so it reads without a legend.
- Barker is the Oracle CASE style of crow's foot and fits Oracle-trained readers.
- IDEF1X makes the identifying relationship visible: the child's key includes the parent's key.
Chen notation and what it is good for
You have a model that three groups will read, and each group expects different symbols. The ER diagram notation you pick decides who reads it without help. For most technical readers that is crow's foot. Chen, Barker, IDEF1X and UML each fit one specific reader, and the sections below say which.
Chen notation is the original. Peter Chen published entity-relationship modeling in a 1976 paper[1]. Entities are rectangles and attributes are ovals. Relationships are labelled diamonds between the entities.
The diamond is what sets Chen apart. A relationship is an object of its own, so it can carry attributes. A fact about the link itself, such as the date a user joined a team, has a place to sit.
That clarity has a price on a real schema. Every attribute gets its own shape, so the ovals grow faster than the tables. The ER model reference says it plainly: "Attributes are often omitted as they can clutter up a diagram." A fifty-table model in full Chen is hard to read on one page. Chen works in a classroom or an early workshop. It rarely survives into a production model.
For what each symbol means, see Entity Relationship Diagram (ERD): Symbols, Examples, and How to Create One. This article is about choosing between the notations.
Crow's foot and Information Engineering
Crow's foot is the compact choice for a working schema. Entities are boxes with the columns listed inside. Everything about a relationship sits at the two ends of its line.
Crow's foot dates back to an article by Gordon Everest from 1976[1], and Information Engineering uses it too. Three marks do the work: a ring for zero, a bar for one and the crow's foot for many. The inner mark gives the minimum and the outer mark the maximum. You read both straight off the line, with no legend.
The limit is the one Chen does not have. In crow's foot, relationships cannot have attributes[1]. A link that carries data becomes a table of its own.
We checked this on a real schema. The demo database below has 14 tables and runs on PostgreSQL 16.14. It already stores two links with data as tables of their own:
| Table | Columns besides the two keys |
|---|---|
| task_assignees | assigned_at |
| team_members | role, joined_at |
In Chen, both would be diamonds with attributes. In crow's foot, both are boxes.
Barker, IDEF1X and UML class diagrams
Barker notation[2] is the style of Oracle's CASE modelling tools. Richard Barker, Ian Palmer, Harry Ellis and others developed it at the British consulting firm CACI around 1981.
Barker is a variant of crow's foot. It shows an optional relationship as a dashed half of the line. Attributes stay inside the boxes, so a Barker diagram fits far more schema on a page than Chen.
The cost is familiarity. Outside Oracle shops, few readers know the dashed half-line, so you need one line of legend. Inside an Oracle team, nobody does.
IDEF1X and identifying relationships
IDEF1X puts one question first: does the child borrow its identity from the parent? In an identifying relationship, the primary key of the child must contain attributes inherited from the parent[3]. IDEF1X draws it as a solid line. A non-identifying relationship is dashed.
IDEF1X has a standard behind it. NIST announced the IDEF1X standard in December 1993[4]. Since September 2012 it is part of ISO/IEC/IEEE 31320-2:2012. A governance reviewer trained on that standard expects a data model to look like this.
You can count the identifying relationships in your own schema before you choose. This query lists them for PostgreSQL:
SELECT CASE WHEN c.conkey <@ p.conkey THEN 'identifying' ELSE 'non-identifying' END AS relationship,
count(*) AS foreign_keys
FROM pg_constraint c
JOIN pg_constraint p ON p.conrelid = c.conrelid AND p.contype = 'p'
WHERE c.contype = 'f'
GROUP BY 1
ORDER BY 1;
We ran it on 25 October 2026 against the 14-table demo schema:
| relationship | foreign_keys |
|---|---|
| identifying | 6 |
| non-identifying | 17 |
The six identifying keys belong to the three link tables: task_assignees, task_labels and team_members. Their primary keys are made of the parent keys. In IDEF1X those six lines are solid and the other 17 are dashed.
The discipline has a cost. IDEF1X needs a primary key for every entity and role names on foreign keys. Its key-style language supports relational and extended relational databases[4]. That is a good fit for formal logical design. It is a poor fit for a sponsor meeting.
UML class diagrams as the fifth notation
A software team may already read UML class diagrams. A class is a box with three parts: the name, the attributes and the operations. The Object Management Group publishes UML[5], and version 2.5.1 is the current specification.
Class diagrams can also be used for data modeling[6]. For a team of developers, that is the appeal: one diagram style for code and data, and nothing new to learn.
The cost shows at the edges. A table has no operations, so that part of the box stays empty. Aggregation and composition describe objects, not keys and constraints. A DBA or a governance reviewer gets less from UML than a developer does.
Choosing by who has to read the diagram
The reader decides the notation, not your own taste. The same model goes to a design review, a governance audit and a business workshop. Each room reads a different set of symbols.
| Reader | Reads without a legend | Slows them down |
|---|---|---|
| Application developers | Crow's foot, UML class diagrams | Chen attribute ovals |
| Data-governance reviewer | IDEF1X | Boxes with no key convention |
| Non-technical stakeholder | Crow's foot or Barker boxes | Chen diamonds, UML operations |
The model level points the same way. A conceptual model is used to discuss initial requirements with the business stakeholders[7]. The physical model goes to the deployment review. Choose the notation for the room each diagram goes to. Keys and normal forms are their own topic, covered in Normal Forms Without the Theory.
One mistake undoes any choice: mixing notations inside one model. If readers first have to work out which convention a diagram uses, the notation has stopped helping them. Use one notation per model and write it down.
Where each notation stops working
Each notation has a limit you can name when you defend your choice. None of them makes a notation wrong.
Chen stops working at scale. The attribute ovals grow faster than the tables, which is why Chen diagrams often leave attributes out.
Crow's foot stops when a relationship needs attributes. The link has to become a table, as task_assignees and team_members did above.
IDEF1X stops at its own assumptions. Its key-style language was defined for relational databases. Its demand for a primary key per entity also slows early conceptual work, while the structure is still under debate.
UML brings in parts a database diagram does not need. Operations and object lifecycles mean nothing to a table. The ER literature also notes that UML's look-across notation does not represent participation constraints well on relationships between more than two entities[1].
Settling on one notation for your model
Pick one notation per readership and write the choice down where the team sees it. A note on the diagram or a line in the model's README is enough.
Different readers wanting different views is not a notation problem. In DbSchema, one model holds as many diagrams as you need, and a table can show on several diagrams. Choose Diagram → New Diagram and include only the tables one room needs. A governance diagram and a developer diagram then sit side by side over the same schema.
The notation itself is a display setting. In DbSchema 10.5.2 you set it in View → Foreign Keys → Foreign Key Notation. The options are Information Engineering With Arrows (the default), Information Engineering, Barker and Idef1x. The documentation is exact about the effect: "The notation changes only the diagram. The model and the database stay the same." DbSchema has no Chen or UML option. For a team that reads UML class diagrams, Information Engineering lists the columns inside each box, as a class lists its attributes.
That makes the choice cheap to test. Switch the notation, show the diagram to one reader from each room, and keep the one they read fastest. If the schema already exists, connect DbSchema to the database. DbSchema reverse-engineers the tables and foreign keys into a diagram, as the MySQL ER diagram guide shows.
Download DbSchema Community Edition and connect it to one of your own schemas. Then switch the foreign key notation and see how each one reads at real scale. Community covers connecting, reverse-engineering and interactive diagrams. Saving the model to a file needs DbSchema Pro.
Frequently asked questions
What are the notations for an ER diagram?
The five you will meet are Chen, crow's foot (Information Engineering), Barker, IDEF1X and UML class diagrams. Chen uses diamonds for relationships, the crow's foot family draws cardinality at the line ends, and IDEF1X marks identifying relationships.
What is crow's foot notation?
Crow's foot draws entities as boxes and puts cardinality at the line ends: a ring for zero, a bar for one and a crow's foot for many. The inner mark is the minimum and the outer mark the maximum.
What is the difference between Chen and crow's foot notation?
Chen draws attributes as separate ovals and relationships as diamonds that can hold attributes. Crow's foot lists attributes inside the box, which keeps large schemas compact.
Which ER notation should a team use?
The one its readers already know. Crow's foot is the safe default for mixed technical readers, IDEF1X for governance reviews and UML for software teams.
What is Barker notation?
Barker is the crow's foot variant used by Oracle's CASE tools. It shows optionality as a dashed half of the line and keeps attributes inside the boxes.
Can one model be shown in more than one notation?
Yes. The notation only changes how the lines are drawn, so the same model can be shown in Information Engineering, Barker or Idef1x without redrawing it.
Sources
Open your own schema and switch the notation
DbSchema reverse-engineers a live database into an interactive ER diagram, and the foreign-key notation is a View setting you can change while you read it. The free Community Edition covers connecting, reverse-engineering, interactive diagrams and the SQL editor.
