Reference · ER diagram symbols
Chen notation for ER diagrams: every symbol, cardinality and a worked example
In short
Chen notation is the original entity-relationship diagramming style from Peter Chen's 1976 paper. It draws entities as rectangles, attributes as ovals hanging off them, and relationships as named diamonds between entities, with the cardinality written as 1, N or M next to each entity. Later textbooks added double rectangles for weak entities, double diamonds for identifying relationships, double lines for total participation, dashed ovals for derived attributes, double ovals for multivalued attributes and (min,max) pairs. This page tabulates all of them, compares Chen with crow's foot and UML, works a university example and gives the three rules for turning a Chen diagram into relational tables.
Updated · by the ChartCraft team · Notasi Chen (Bahasa Indonesia)
What are the symbols in Chen notation?
Fourteen symbols cover every Chen diagram you will meet: four shapes (rectangle, oval, diamond, line) with single or double borders and a few decorations — underline for keys, dashes for derived and partial. The right-hand column gives what each becomes in a relational schema.
| Symbol | Name | Meaning | Becomes in SQL |
|---|---|---|---|
| Entity (strong) | Rectangle. A thing the database stores facts about: STUDENT, COURSE. Has its own key. | Table | |
| Weak entity | Double rectangle. Cannot be identified without its owner entity — SECTION only means something inside its COURSE. | Table whose primary key includes the owner's key | |
| Attribute | Oval joined to its entity or relationship by a line. | Column | |
| Key attribute | Oval with the name underlined. Identifies one instance of the entity uniquely. | Primary key | |
| Partial key (discriminator) | Oval with a dashed underline, on a weak entity. Unique only within one owner: sec_no within a COURSE. | Part of a composite primary key | |
| Multivalued attribute | Double oval. Can hold several values at once: phone numbers. | Separate table (entity key + value) | |
| Derived attribute | Dashed oval. Computed from other data: age from dob. | No column (or a computed/view column) | |
| Composite attribute | Oval with sub-attribute ovals hanging off it: name → first, last. | One column per leaf sub-attribute | |
| Relationship | Diamond named with a verb, connected to two (or more) entities. | Foreign key, or a junction table for M:N | |
| Identifying relationship | Double diamond. Links a weak entity to its owner. | Foreign key inside the weak entity's primary key | |
| Relationship attribute | An oval attached to a diamond: grade on enrolls in. A fact about the pair, not about either entity. | Column in the junction table (M:N) or on the FK side (1:N) | |
| Total participation | Double line between entity and diamond. Every instance of the entity takes part at least once. | NOT NULL foreign key | |
| Partial participation | Single line. Instances may take part zero times. | Nullable foreign key | |
| Cardinality ratio | 1, N or M written on the line next to each entity: 1:1, 1:N, M:N. | Decides where the foreign key goes (see below) |
Chen's 1976 paper defined the rectangle, diamond, attribute values and the 1/N cardinality labels. The double-border conventions, derived/multivalued ovals and (min,max) pairs are the “extended ER” additions popularised by database textbooks such as Elmasri & Navathe's Fundamentals of Database Systems; they are what most courses now call Chen notation.
How is cardinality written in Chen notation?
Two ways, often together. The cardinality ratio writes 1, N or M on the line next to each entity and is read across the diamond: “one DEPARTMENT offers N COURSEs.” The (min,max) pair is written next to an entity and is read on that side: COURSE (1,1) means every course participates in offers exactly once. Total participation (double line) is shorthand for min = 1.
| Notation | Meaning | Example | Consequence in the schema |
|---|---|---|---|
1 : 1 | One instance of A relates to at most one B, and vice versa. | DEPARTMENT managed by EMPLOYEE | Foreign key on the side with total participation (or either side) |
1 : N | One A relates to many B; each B relates to one A. | DEPARTMENT offers COURSE | Foreign key on the N side (COURSE gets dept_id) |
N : 1 | The same as 1:N read from the other entity. | COURSE offered by DEPARTMENT | Foreign key on the N side |
M : N | Many A to many B. | STUDENT enrolls in SECTION | New junction table with both keys |
(min, max) | Structural constraint written next to an entity: how many times each instance participates, from min to max. (1,1) = exactly once; (0,N) = any number including none. | COURSE (1,1) — offers — (0,N) DEPARTMENT | min ≥ 1 ⇒ NOT NULL; max = N on the opposite side ⇒ that side holds the FK |
| Double line | Total participation — shorthand for min = 1. | COURSE ═ offers | NOT NULL |
| Single line | Partial participation — min = 0. | STUDENT — enrolls in | Nullable, or simply absent rows in the junction table |
The two conventions look at the relationship from opposite sides. A ratio label sits next to entity B but counts B-instances per A-instance (look-across); a (min,max) pair sits next to entity A and counts how many times each A-instance participates (look-here). In a 1:N offers relationship the N is written next to COURSE, while COURSE's pair is (1,1). Do not mix the two systems on one line end.
What does a complete Chen ER diagram look like?
The university diagram below uses every symbol from the table: four entities (one weak), three relationships (one identifying), key, partial-key, multivalued and derived attributes, a relationship attribute, total participation and all three cardinality ratios.
| Element | Symbol used | Reading |
|---|---|---|
| DEPARTMENT, COURSE, STUDENT | Single rectangle | Strong entities, each with an underlined key |
| SECTION | Double rectangle | Weak entity; sec_no (dashed underline) is unique only within one COURSE |
| offers | Diamond, 1 at DEPARTMENT, N at COURSE, double line to COURSE | A department offers many courses; every course is offered by exactly one department |
| has | Double diamond, 1 at COURSE, N at SECTION, double line to SECTION | Identifying relationship; a section cannot exist without its course |
| enrolls in | Diamond, M at STUDENT, N at SECTION, oval grade on the diamond | Many-to-many; grade is a fact about the (student, section) pair |
| phone | Double oval | A student may have several phone numbers |
| age | Dashed oval | Derived from dob — never stored |
Mermaid has no Chen grammar, but the same model in crow's foot form is a four-line erDiagram — see crow's foot notation for how the marks map:
erDiagram
DEPARTMENT ||--|{ COURSE : offers
COURSE ||--|{ SECTION : has
STUDENT }o--o{ SECTION : "enrolls in"How do you convert a Chen diagram to relational tables?
Three rules, applied in order: (1) every entity becomes a table — weak entities borrow the owner's key, multivalued attributes get their own table, derived attributes are dropped; (2) every 1:1 and 1:N relationship becomes a foreign key on the N side (or the total side for 1:1); (3) every M:N relationship becomes a junction table holding both keys plus any relationship attributes.
| Rule | Applies to | What you create |
|---|---|---|
| 1. Entity → table | Strong entity | One table; key attribute → primary key; composite attribute → one column per leaf; derived attribute → nothing |
| Weak entity | One table whose primary key = owner's primary key + partial key; the owner key is also a foreign key | |
| Multivalued attribute | A separate table (owner key, value) with a composite primary key | |
| 2. 1:N / 1:1 → foreign key | 1:N relationship | Add the 1-side primary key as a foreign key column on the N side; NOT NULL if participation is total; relationship attributes go on the same side |
| 1:1 relationship | Foreign key on whichever side has total participation (either side if both or neither) | |
| 3. M:N → junction table | M:N relationship | A new table with both primary keys as foreign keys, composite primary key over both, plus one column per relationship attribute |
The university example converted
| Diagram element | Rule | Resulting table |
|---|---|---|
| DEPARTMENT | Rule 1 (entity) | DEPARTMENT(dept_id PK, name) |
| COURSE + offers 1:N | Rule 2 (1:N → FK on the N side; total ⇒ NOT NULL) | COURSE(course_no PK, title, credits, dept_id FK NOT NULL) |
| SECTION (weak) + has | Rule 1 (weak entity: owner key + partial key) | SECTION(course_no FK, sec_no, semester, PK(course_no, sec_no)) |
| STUDENT | Rule 1 (entity; derived attribute dropped) | STUDENT(student_id PK, dob) — age is computed, not stored |
| STUDENT.phone (multivalued) | Rule 1 (multivalued → own table) | STUDENT_PHONE(student_id FK, phone, PK(student_id, phone)) |
| enrolls in M:N with grade | Rule 3 (M:N → junction table; relationship attribute becomes a column) | ENROLMENT(student_id FK, course_no FK, sec_no FK, grade, PK(student_id, course_no, sec_no)) |
The same rules, applied by hand or by a tool, are why Chen notation is taught first: the mapping from diagram to CREATE TABLE is mechanical. For the step-by-step process see how to make an ER diagram.
How does Chen notation compare with crow's foot and UML?
Chen is the most explicit and the most space-hungry: attributes are separate shapes and every relationship is a diamond. Crow's foot compresses attributes into the entity box and puts cardinality on the line ends; UML class diagrams do the same with 0..* multiplicities. Same model, three drawings.
| Aspect | Chen | Crow's foot (IE) | UML class diagram |
|---|---|---|---|
| Relationship | Named diamond between the entities | Plain line; the verb is a label on the line | Plain line (association); verb optional |
| Attributes | One oval per attribute, lines to the entity | Listed inside the entity box | Listed in the class compartment with types |
| Key | Underlined attribute name | PK tag in the box | Property marked {id} or a stereotype |
| One-to-many | 1 and N next to the entities | || on the one side, o{ / |{ on the many side | 1 and 0..* / 1..* on the association ends |
| Optionality | Single vs double line (partial vs total), or (min,max) | Inner mark: circle (zero) or bar (one) | Lower bound of the multiplicity: 0..1, 1 |
| Many-to-many | M and N; attributes hang off the diamond | Crow's feet on both ends; usually resolved into a junction table | * on both ends; attributes go on an association class |
| Weak entity | Double rectangle + double diamond | Identifying relationship = solid line, non-identifying = dashed | Composition (filled diamond) |
| Where you will meet it | Textbooks, database courses, academic papers | Database tools, ORMs, most working ERDs | Software design, UML-centric teams |
| Mermaid support | No native Chen grammar | erDiagram draws crow's foot | classDiagram draws multiplicities |
ChartCraft's ER diagram generator draws crow's foot. Describe the model in plain English (“a department offers many courses; students enrol in sections and get a grade”) and it chooses the marks; the Chen reading of the result follows the table above. The full symbol hub is at ER diagram symbols.
Where does Chen notation come from?
From Peter Pin-Shan Chen, “The Entity-Relationship Model — Toward a Unified View of Data”, ACM Transactions on Database Systems, vol. 1, no. 1, March 1976, pp. 9–36. The paper proposed entities, relationships and attributes as a semantic layer above the relational, network and hierarchical models of the time, and introduced the rectangle/diamond diagram with 1 and N labels.
Chen's diagram was intended as a conceptual design tool — a drawing to agree on before any tables exist — which is still the best way to use it. Physical schemas, ORMs and database tools moved to crow's foot (Information Engineering notation) and Barker notation in the 1980s because they fit more on a page; the conceptual vocabulary is unchanged.
What do these models look like drawn by ChartCraft?
The public gallery draws ER diagrams in crow's foot notation; the Chen reading of each is given by the tables on this page. Every diagram was generated from a plain-English description — open one to see the prompt.
Frequently asked questions
What is Chen notation?
Chen notation is the ER diagramming style introduced by Peter Chen in 1976: rectangles for entities, ovals for attributes, diamonds for relationships, and 1 / N / M labels for cardinality. Extended Chen adds double shapes for weak entities, identifying relationships and multivalued attributes, dashed ovals for derived attributes and (min,max) pairs.
What does the diamond mean in Chen notation?
A relationship between entities, named with a verb: STUDENT — enrolls in — SECTION. A double diamond is an identifying relationship that links a weak entity to its owner. Attributes can hang off a diamond when the fact belongs to the pair, like a grade.
What is the difference between 1:N and (min,max) in Chen notation?
1:N is a cardinality ratio read across the diamond: one A relates to N B. (min,max) is a participation constraint read on one side: how many times each instance of that entity takes part. The N of a 1:N relationship is written next to the many entity, whose (min,max) pair is (0,1) or (1,1).
What is a weak entity in Chen notation?
An entity drawn with a double rectangle that cannot be identified by its own attributes alone — a SECTION needs its COURSE. It has a partial key (dashed underline) and is connected to its owner through an identifying relationship (double diamond) with total participation (double line). In SQL its primary key combines the owner's key and the partial key.
What does the double line mean in a Chen ER diagram?
Total participation: every instance of that entity must take part in the relationship at least once. A single line is partial participation (zero allowed). In the schema, total participation on the foreign-key side becomes a NOT NULL constraint.
How do you convert Chen notation to tables?
Three rules: each entity becomes a table (weak entities add the owner's key, multivalued attributes get their own table, derived attributes are dropped); each 1:N or 1:1 relationship becomes a foreign key on the N side or the total side; each M:N relationship becomes a junction table with both keys and the relationship's attributes.
Is Chen notation the same as crow's foot?
No. They draw the same model differently. Chen uses diamonds and ovals with 1/N labels; crow's foot drops the diamonds, lists attributes inside the entity box and puts bar, circle and crow's-foot marks on the line ends. Crow's foot is what database tools and Mermaid's erDiagram draw.
Does Mermaid support Chen notation?
No. Mermaid's erDiagram grammar draws crow's foot only (e.g. DEPARTMENT ||--|{ COURSE : offers). To publish a Chen diagram you draw it by hand or use a tool that supports the notation; the SVG on this page was composed that way.