Chen Notation and Conceptual Modeling

Learning outcomes

Chen notation is closely associated with the original Entity-Relationship model proposed by Peter Chen. It emphasizes conceptual structure: entity types, attributes, relationship types, identifiers, participation, and relationship degree. Compared with table-oriented diagrams, Chen notation can make the domain model more explicit before implementation decisions dominate the conversation.

The conceptual emphasis

Chen notation is especially useful when the main question is “What does the business mean?” rather than “Which table stores this foreign key?” A conceptual review can therefore focus on Customer, Asset, WorkOrder, Technician, ownership, assignments, identifiers, and business constraints without discussing indexes or SQL types.

Core Chen symbols

Representing attributes explicitly

Chen notation can visually distinguish attribute types that table-oriented diagrams often flatten into columns. For Customer, you might conceptualize:

Customer  customer_id       [key]  legal_name  contact_name  phone_number      [potentially multivalued]  registered_at  account_age       [derived]

account_age is derived from registered_at and the current time. If phone numbers have type, verification, and history, they may eventually become a separate entity instead of remaining a multivalued attribute.

Composite attributes

Chen notation can show a composite attribute with subattributes. An Address might be represented as:

This expresses semantic composition. In the relational model, those components may become separate columns, a structured type, or an Address entity depending on requirements.

Relationships are first-class diagram elements

In Chen notation, the relationship often appears as a named diamond between entity rectangles:

This makes the verb visually prominent. It encourages reviewers to ask whether “owns” means current ownership, legal ownership, responsibility for billing, or merely who registered the asset.

Cardinality in Chen notation

Cardinality can be shown using labels such as 1, N, M, or min-max pairs. Tool conventions vary. A conceptual statement such as:

says one Customer may participate in ownership relationships with many Assets, while each Asset participates with one Customer under the current scope. To express optionality precisely, annotate minimum participation as well.

Total and partial participation

Traditional Chen notation can use double lines for total participation and single lines for partial participation.

For WorkshopHub:

• WorkOrder has total participation in SERVICES because every WorkOrder must service one Asset.
• Asset has partial participation because a newly registered Asset may have no WorkOrders.

The same business rule can be written as 1..1 from WorkOrder to Asset and 0..* from Asset to WorkOrder.

Relationship attributes in Chen notation

Chen notation can attach attributes directly to a relationship. Suppose Technician ASSIGNED_TO WorkOrder has:

• started_at;
• ended_at;
• role.

Conceptually, those values can appear as attributes of the ASSIGNED_TO relationship. When mapping to a relational schema, the many-to-many relationship becomes WorkOrderAssignment and those relationship attributes become columns of that associative table.

Weak entities

Suppose WorkOrderLine is identified by WorkOrder plus line_number. In Chen notation:

• WorkOrderLine is drawn as a weak entity;
• line_number is a partial key;
• the identifying relationship to WorkOrder is distinguished;
• WorkOrderLine has total participation in that identifying relationship.

This representation communicates the semantic dependence before choosing whether the physical schema will later add a surrogate key.

Ternary relationships are explicit

Chen notation is useful for relationships of degree greater than two because the relationship diamond can connect three entity types directly:

             [Supplier]                 |                 |              <SUPPLIES>              /        \          [Part]     [Warehouse]

If agreed price depends on Supplier + Part + Warehouse together, the ternary structure communicates the fact more faithfully than three pairwise lines.

Conceptual WorkshopHub fragment

[Customer] -- <OWNS> -- [Asset]                          |                          |                      <SERVICED_BY>                          |                     [WorkOrder]                       /       \                      /         \             <ASSIGNED>      <USES>                /               \        [Technician]            [Part]

At this level, the diagram emphasizes domain relationships. A later logical model would introduce WorkOrderAssignment and PartUsage explicitly and show candidate/foreign keys.

Mapping Chen concepts to relations

When Chen notation is helpful

Use it when:

• teaching or learning ER fundamentals;
• conceptual relationships need to be highly visible;
• relationship attributes and higher-order relationships matter;
• business stakeholders can review a simplified semantic diagram.

Use a more table-oriented notation when the audience needs direct visibility into foreign keys, normalized tables, and physical schema details.

Do not argue notation instead of semantics

Two teams can draw the same correct model using Chen, Crow's Foot, IDEF1X, UML, or a tool-specific notation. The most important questions remain:

• What entities exist?
• What identifies them?
• What relationships exist?
• What are the minimum and maximum cardinalities?
• Which facts belong to the relationship?
• What is optional, historical, or state-dependent?

Practice: conceptual first

Summary and next lesson

Chen notation makes entities, attributes, relationship types, participation, weak entities, and higher-order relationships explicit. It is particularly valuable for conceptual modeling. The next lesson explores UML class diagrams, which use a different vocabulary but can also communicate data structures and multiplicities effectively.

References

• Peter P. Chen, “The Entity-Relationship Model—Toward a Unified View of Data,” 1976.
• Ramez Elmasri and Shamkant B. Navathe, Fundamentals of Database Systems.
• Martin Fowler, UML Distilled.