This sample models a small lending library in Chen notation: authors write books, the library owns physical copies of each book, and members borrow copies. Chen diagrams show entities as rectangles, relationships as diamonds and attributes as ovals.
It also shows a weak entity (COPY), which cannot be identified without its owning BOOK.
1. The Diagram
Read the diagram from left to right, then down from BOOK.
AUTHOR and BOOK are strong entities (single rectangles), each with an underlined key attribute: author_id and isbn.
The WRITES diamond joins them with M and N on the lines: an author writes many books and a book can have many co-authors.
COPY is a weak entity (double rectangle). Copy number 3 means nothing on its own; it is copy 3 of a given book. Its partial key copy_no has a dashed underline.
HAS is the identifying relationship (double diamond) that lends COPY the book's key. The double line from HAS to COPY is total participation: every copy must belong to a book.
BORROWS links MEMBER and COPY many-to-many over time. borrow_date and due_date hang off the diamond because they describe the loan, not the member or the copy.
phone is multivalued (double oval: a member may list several numbers) and num_copies is derived (dashed oval: computed, not stored).
2. How to Read It
Chen notation, introduced by Peter Chen in 1976, draws relationships and attributes as shapes of their own. Cardinality ratios (1, N, M) are written on the lines, and a double line means every instance of that entity must take part. Some texts use (min,max) pairs on the lines instead of 1/N.
3. Variant: Mapping to Tables
Turning the Chen model into tables follows mechanical rules. The weak entity copy takes the owner's key plus its partial key as a composite primary key. The many-to-many relationship BORROWS becomes its own table, loan, whose key includes borrow_date so the same member can borrow the same copy again later. The multivalued phone would become a separate member_phone table.
4. Pros, Cons, and When to Use
Pros
Separates entities, relationships and attributes visually; good for teaching.
Relationships can carry their own attributes naturally.
Weak entities, multivalued and derived attributes have explicit symbols.
Technology-neutral: a conceptual model, not a table design.
Good for workshops with domain experts before any schema exists.
Cons
Takes much more space than crow's foot; large models sprawl.
No standard place for data types, indexes or foreign keys.
Fewer tools support it (PlantUML, draw.io, Lucidchart do).
1/N ratios alone hide optionality unless (min,max) is added.
Rarely used in industry design reviews, so readers may be unfamiliar.
When to use
Conceptual modelling and requirements discussions.
Teaching ER modelling and normalisation.
Explaining weak entities and relationship attributes.
When not to use
Physical schema documentation (use a logical schema diagram).
Schemas with more than about 15 entities.
5. As Diagrams-as-Code
PlantUML has a Chen mode, @startchen:
@startchen
entity AUTHOR { author_id <<key>>
name }
entity BOOK { isbn <<key>>
title
pub_year
num_copies <<derived>> }
entity COPY <<weak>> { copy_no <<partial key>>
condition }
entity MEMBER { member_id <<key>>
name
phone <<multi>> }
relationship WRITES {}
relationship HAS <<identifying>> {}
relationship BORROWS { borrow_date
due_date }
AUTHOR -M- WRITES
WRITES -N- BOOK
BOOK -1- HAS
HAS =N= COPY
COPY -N- BORROWS
BORROWS -M- MEMBER
@endchen
The = connector draws total participation as a double line.