Designing a well-structured database starts with understanding how to represent data and its relationships clearly. One of the most influential tools for this is Chen notation, a visual language used in Entity-Relationship diagrams.
This guide walks you through the key parts of Chen notation—entities, attributes, relationships, cardinality, and more. Whether you’re a student learning about database design for the first time or someone brushing up on your ER modeling skills, you’ll find clear explanations and practical insights to help you use Chen notation with confidence.
What Is Chen Notation?
Chen notation is a visual modeling technique used to design the structure of a database before it’s built. It was introduced by Peter Chen in 1976 in his groundbreaking paper “The Entity-Relationship Model: Toward a Unified View of Data.”
This notation became the foundation of what is now widely known as Entity-Relationship modeling, a standard method for planning and communicating the structure of a database system.
Purpose of Chen notation
The main purpose of Chen notation is to help designers, developers, and stakeholders visualize how data is organized and how different pieces of data are connected. It provides a clear, high-level picture of the database’s contents and their relationships—before any actual data is stored or code is written.
Think of Chen notation as the blueprint of a database, just like architectural plans are blueprints for buildings. It helps:
- Understand what data needs to be stored
- Determine how different data elements relate to each other
- Identify what information is essential and how it flows across the system
Chen Notation Symbols
Chen notation is built using a few basic shapes, each with a specific meaning. These simple ER diagram symbols make it easy to communicate ideas clearly, even to people who don’t write code or work with databases regularly.
Entities in Chen Notation
In Chen notation, entities represent real-world objects or concepts that are important in a database system. An entity can be something concrete like a person, product, or event, or something abstract like a project or class. Essentially, entities are the building blocks of a database design.
Representation of entities:
- Rectangles are used to represent entities in Chen notation.
- Each rectangle is labeled with the name of the entity (e.g., Student, Course, Employee).
Think of an entity as a category of information you want to store. For example, in a school database:
- “Student” is an entity that represents all the students.
- “Course” is an entity that represents the courses offered.
Strong vs. weak entities
Entities can be classified as strong or weak based on their dependence on other entities for identification.
1. Strong entities
A strong entity is an entity that can exist on its own. It doesn’t need the help of other entities to be uniquely identified. Strong entities are represented with simple rectangles in Chen notation. A strong entity has a primary key—a unique attribute (like Employee ID) that distinguishes each instance of the entity.
Example: Think of an Employee in a company. An employee has a unique Employee ID that can identify them, and no other entity is required to uniquely define them.
2. Weak entities
A weak entity depends on another entity (called the owner or strong entity) for its identification. A weak entity cannot be uniquely identified on its own, so it needs to be connected to a strong entity. Weak entities are drawn with double rectangles in Chen notation to indicate their dependency on a strong entity.
A weak entity doesn’t have its own primary key. Instead, it has a partial key, which is only unique within the context of its owner (the strong entity). For example, the Dependent entity might be identified by the Employee ID (the strong entity) and the Dependent’s Name (the partial key).
Example: A Dependent (like a spouse or child) is a weak entity. You can’t identify a dependent without knowing which Employee they belong to. The dependent relies on the Employee entity for identification.
3. Associative entities (also known as Bridge entities)
An associative entity is used to represent a many-to-many relationship between two entities. It breaks down a many-to-many relationship into two one-to-many relationships. Associative entities have relationships with the two entities they link and often include additional attributes specific to the relationship (e.g., the date a student enrolled in a course, or the grade the student received).
In Chen notation, we use an associative entity to represent this many-to-many relationship. The associative entity might be called something like Enrollment and will include attributes such as Enrollment Date or Grade, in addition to connecting the two original entities (Student and Course).
Example: In a Student-Course relationship, a student can enroll in many courses, and a course can have many students. The many-to-many relationship needs to be represented in a way that a database can handle easily. Associative entities are represented as rectangles just like other entities, but their purpose is to connect two entities in a many-to-many relationship.
How it all fits together
Let’s put it all together with a practical example. Imagine you are designing a university database:
- Entities: You have two entities: Student and Course.
- Relationship: A Student can enroll in multiple Courses, and each Course can have many Students. This is a many-to-many relationship.
- Associative entity: To handle this many-to-many relationship, you introduce an associative entity called Enrollment, which connects Student and Course. The Enrollment entity might have its own attributes, such as Enrollment Date or Grade.
In this scenario:
- Student and Course are strong entities.
- Enrollment is an associative entity representing the many-to-many relationship between the Student and Course.
- Attributes for the Student entity could include Student ID (key), Name, Email, and for the Course entity, Course ID, Course Name.
Attributes in Chen Notation
In Chen notation, attributes describe the properties or characteristics of entities (and sometimes relationships). They help define the details you want to capture about something in your database.
For example, if the entity is a Student, the attributes could include the student’s name, ID number, email address, and date of birth. These details give context to the entity and help distinguish one instance from another.
How attributes are shown in Chen notation
- Attributes in ER diagrams are drawn as ovals (ellipses).
- Each oval is connected to the entity (or relationship) it describes using a straight line.
- The name of the attribute is written inside the oval.
Types of attributes in Chen notation
Chen notation recognizes several types of attributes, each with specific characteristics. Understanding these types helps you model data more accurately and logically.
1. Simple (atomic) attributes
- These are basic, indivisible values.
- Each holds just one value, and that value can’t be split further.
Example: A student’s email address, age, or employee ID. In the diagram this is shown as a single oval connected to the entity.
2. Composite attributes
- These attributes are made up of multiple smaller attributes.
- They group related pieces of information into one.
Example: Full Name could be broken into First Name and Last Name. Address might include Street, City, State, and ZIP Code. In the diagram, the main attribute (e.g., “Address”) is an oval, with lines connecting it to its sub-attributes, which are also ovals.
3. Derived attributes
- A derived attribute is not stored directly in the database. Instead, it’s calculated from other stored attributes.
Example: Age can be calculated from Date of Birth. Total Price could be derived from Quantity × Unit Price. In the diagram this is shown as a dashed oval.
4. Multivalued attributes
- These attributes can have more than one value for a single entity.
Example: A person might have multiple phone numbers or email addresses. In the diagram this is shown as a double oval.
5. Key attributes
- A key attribute is used to uniquely identify each instance of an entity.
- Every strong entity must have at least one key attribute.
Example: Student ID, Employee Number, or Product Code. In the diagram, the key attribute is underlined inside the oval.
6. Partial key attributes
- Used only with weak entities.
- A partial key by itself cannot uniquely identify the entity.
- It must be combined with a key attribute from the related strong entity.
Example: A dependent’s Name in a “Dependent” entity might only be meaningful when combined with the related Employee ID. In the diagram, this is shown as an underlined dashed oval.
Can attributes describe relationships too?
Yes! While attributes usually describe entities, they can also be used to describe relationships, especially in associative entities.
Example: In a many-to-many relationship between Student and Course, the relationship Enrollment might have attributes like:
- Date of Enrollment
- Grade
These attributes are attached to the relationship diamond, just like they would be with an entity.
Relationships in Chen Notation
In Chen notation, ERD relationships show how entities are connected to each other in a database. If entities are the nouns (like Student or Course), relationships are the verbs that link them (like enrolls in, manages, or belongs to).
They help us understand how data interacts, and they form the bridge between different entities in a meaningful way.
How relationships are represented
- Relationships are drawn as diamonds.
- Each diamond is labeled with a verb or descriptive phrase that shows how the entities are related.
- Lines connect the relationship diamond to the participating entities (represented by rectangles).
Types of relationships in Chen notation
There are different types of relationships, depending on how many instances of one entity relate to instances of another. These are known as cardinality or degree of relationships.
1. One-to-one (1:1): In one-to-one relationship, each instance of one entity is related to only one instance of the other.
2. One-to-many (1:N): In one-to-many relationship, one entity instance is related to many instances of the other entity.
3. Many-to-many (M:N): In many-to-many relationship, many instances of one entity relate to many instances of another.
Relationship attributes
Relationships, just like entities, can have attributes. These are useful when the relationship itself carries data.
Example: In the Enrollment relationship between Student and Course, you might want to store:
- Date of Enrollment
- Grade
These attributes describe the relationship, not the student or course alone.
Participation constraints
These constraints describe whether every instance of an entity must participate in a relationship.
1. Total participation
- Every instance of the entity must be involved in the relationship.
- Shown using a double line between the entity and the relationship.
Example: Every Employee must be assigned to a Department.
2. Partial participation
- Some instances of the entity may not participate in the relationship.
- Shown using a single line.
Example: Some Customers might not place any Orders yet.
Degree of a relationship
This refers to the number of entity types involved:
- Binary (most common): Involves two entities (e.g., Student — Enrolled In — Course)
- Ternary: The ternary relationship in ER diagrams involves three entities (e.g., Doctor — Treats — Patient — Using — Medicine)
- N-ary: Involves more than three (less common and harder to implement in relational databases)
Identifying vs. Non-identifying relationships
This concept is especially important when dealing with weak entities.
- An identifying relationship is used when a weak entity relies on a strong entity to be uniquely identified.
- Represented by a double diamond.
- The weak entity gets part of its key from the related strong entity.
Cardinality and Participation
In Chen notation, cardinality and participation are two important concepts that help define how entities are related to each other in a database. They describe how many instances of an entity can or must be associated with another entity in a relationship.
Let’s break them down simply and clearly.
Cardinality in Chen notation
Cardinality refers to the number of instances of one entity that can or must be related to the number of instances of another entity. It answers the question: “How many of one entity can be associated with how many of the other?”
There are three basic types of cardinality in Chen notation:
- One-to-one (1:1)
One instance of Entity A is related to only one instance of Entity B, and vice versa.
Example: Each Person has one Passport, and each Passport is assigned to one Person.
- One-to-many (1:N)
One instance of Entity A can be related to many instances of Entity B, but each instance of Entity B is related to only one instance of Entity A.
Example: One Teacher teaches many Courses, but each Course is taught by one Teacher.
- Many-to-many (M:N)
Many instances of Entity A can be related to many instances of Entity B.
Example: A Student can enroll in many Courses, and each Course can have many Students.
Participation in Chen Notation
Participation defines whether every instance of an entity must take part in a particular relationship.
It answers the question: “Is this relationship optional or required for the entity?”
There are two types:
- Total participation
- Definition: Every instance of the entity must be involved in the relationship.
- Notation: Shown with a double line between the entity and the relationship.
- Example: Every Employee must belong to a Department. So, Employee has total participation in the “Works In” relationship.
- Partial participation
- Definition: Some instances of the entity may not participate in the relationship.
- Notation: Shown with a single line between the entity and the relationship.
- Example: Some Customers may not place any Orders. So, the Customer has partial participation in the “Places” relationship.
Chen Notation vs Crow Foot
When you’re designing a database, ER diagrams help you visualize how different types of data relate to one another. Two of the most widely used styles for these diagrams are Chen notation and Crow’s Foot notation. They both serve the same purpose but differ in how they represent information visually and structurally.
In Chen notation, the parts of the database are represented using distinct shapes. Entities, like “Student” or “Employee,” are shown as rectangles. Attributes, such as a student’s ID or name, are drawn as ovals. Relationships, such as “enrolled in” or “manages,” appear as diamonds connecting the entities. Each element is clearly separated, which makes it easier to understand especially for beginners or when explaining how databases work in a classroom or conceptual setting.
What is Crow’s Foot notation?
Crow’s Foot notation, also known as Information Engineering notation, presents the same information more compactly. Entities are still shown as rectangles, but their attributes are usually listed inside the box, instead of being drawn separately.
Instead of diamonds for relationships, Crow’s Foot uses straight lines with symbols at each end to indicate how the entities relate. These symbols include:
- A line ending in a “crow’s foot” to show “many”
- A vertical bar to show “one”
- A small circle to show “zero” (or optional participation)
Because this notation is more space-efficient, it’s commonly used in real-world database and software development projects, especially when diagrams become large or complex.
1. Key differences in visual style
The biggest difference lies in how clearly each part is separated. In Chen notation, entities, attributes, and relationships each have their own distinct shape. This makes it easier to identify and focus on individual components.
Crow’s Foot notation, by contrast, blends information together—attributes go inside the entities, and relationships are shown with annotated lines. This keeps the diagram cleaner, but may require more familiarity to read quickly.
2. How they show cardinality and participation
In Chen notation, cardinality is often written with numbers near the connecting lines. Participation is shown by using either single or double lines: a double line means that every instance of the entity must be involved in the relationship (called total participation), and a single line means it’s optional.
In Crow’s Foot notation, these ideas are built into the line symbols. For example, a line with a vertical bar and a crow’s foot means “one to many”. A line with a circle and a bar means “zero or one”.
3. When to use each notation
Chen notation is best when you’re focused on understanding or explaining the overall structure of a system. It’s useful during the early stages of design or in academic settings where clarity is more important than space.
Crow’s Foot notation is better suited for practical use in system development. It’s the standard in many modeling tools, works well in large projects, and is favored when space and efficiency matter.
Advantages and Limitations of Chen Notation
Chen notation is one of the earliest and most well-known ways to draw ER diagrams. It helps you clearly show the structure of a database using basic shapes to represent entities, attributes, and relationships. While it’s very useful in many situations, it also has some drawbacks depending on how and where it’s used.
Advantages of Chen notation
1. Easy to understand
Chen notation uses separate shapes for each part of a database—rectangles for entities, ovals for attributes, and diamonds for relationships. This clear visual separation makes it easier for beginners or non-technical stakeholders to understand the structure without needing much background in databases.
2. Conceptually complete
It includes detailed elements like multivalued attributes, derived attributes, weak entities, and participation constraints. This allows you to describe not just what entities exist, but also how they behave and depend on each other.
3. Good for teaching and early design
Because of its simplicity and detail, Chen notation is widely used in academic settings. It’s excellent for explaining fundamental database concepts or starting the early stages of a database design.
4. Makes relationships explicit
Instead of just drawing lines between entities, Chen notation uses diamonds to clearly label relationships and show their direction and meaning. This makes it easy to tell what kind of relationship exists between two entities and how they interact.
Limitations of Chen notation
1. Takes up more space
Because each attribute and relationship is drawn separately with its own shape, Chen notation can quickly become cluttered when the diagram includes many entities. This makes it less practical for large or complex systems.
2. Not commonly used in industry
While useful in the classroom or in early planning, Chen notation is not as widely used in professional environments. Most industry-standard tools and teams prefer Crow’s Foot notation or UML class diagrams because they are more compact and better suited for implementation.
3. Slower to read for experienced users
For someone already familiar with databases, the extra visual elements in Chen notation (like separate ovals and diamonds) can feel unnecessary. Experienced users may prefer a more streamlined view, where information is packed into entity boxes instead of spread out.
4. Limited tool support
Many popular database modeling tools support Chen notation to some extent, but not all of them do. Some tools may simplify or skip parts of Chen’s model in favor of more widely used notations, which can limit how you can apply it in practice.
Common Mistakes and How to Avoid Them
Chen notation is a helpful way to visually represent how a database is organized. But like any modeling method, it’s easy to make small mistakes—especially if you’re new to database design. These mistakes can lead to confusion, incomplete models, or even design problems later on. Below are some of the most common issues and simple tips to avoid them.
Mistake 1: Mixing up entities and attributes
What happens: Sometimes people accidentally treat important data elements (like “Department” or “Course”) as attributes instead of entities. For example, you might show “Department” as an oval (attribute) connected to “Employee,” when it really should be its own rectangle (entity) because departments exist independently.
How to avoid it: Ask yourself: Can this item exist on its own or have other relationships? If yes, it’s probably an entity. Use rectangles for entities and ovals only for values or characteristics that describe those entities.
Mistake 2: Forgetting to show relationship names
What happens: In some diagrams, relationships between entities are drawn using lines, but the connecting diamond is left blank or missing. This makes it unclear what the relationship actually means.
How to avoid it: Always label the diamond with a descriptive verb or phrase. For example, use “teaches,” “enrolls in,” or “belongs to.” This makes the diagram easier to read and understand, especially when sharing it with others.
Mistake 3: Ignoring cardinality and participation
What happens: Many diagrams leave out important details like how many instances of one entity relate to another (cardinality), or whether a relationship is required (participation). This weakens the model because it doesn’t reflect real-world rules.
How to avoid it: Clearly indicate the minimum and maximum number of times an entity can participate in a relationship. In Chen notation, write these numbers (like 1, N, or 0) near the connecting lines. Also, use a double line for total participation and a single line for partial.
Mistake 4: Misrepresenting weak entities
What happens: People often forget to show that a weak entity depends on another entity for its identification. For instance, a “Dependent” entity might be drawn like any other entity, even though it can’t exist without an “Employee.”
How to avoid it: Use a double rectangle for weak entities, and connect them to their identifying (strong) entity through a double diamond. Also, include a partial key attribute that, when combined with the strong entity’s key, forms the full identifier.
Mistake 5: Overloading the diagram
What happens: Trying to include too many entities, attributes, and relationships in a single diagram can make it overwhelming and hard to follow.
How to avoid it: Break complex systems into smaller, related diagrams if needed. Focus on keeping each diagram readable. You can always connect related pieces later or present them in sections.
Mistake 6: Using inconsistent naming
What happens: Using vague or inconsistent names (like “Thing1” or “Data”) makes it difficult for others to understand your model. You might also name similar entities or attributes differently in different parts of the diagram.
How to avoid it: Choose clear, descriptive names that reflect real-world objects or ideas. Be consistent in how you name similar items throughout the diagram.
Brief History and Significance of Chen Notation
Chen notation is named after Dr. Peter Chen, who introduced it in 1976 in his paper “The Entity-Relationship Model: Toward a Unified View of Data.” At the time, there was no clear way to visually represent how data was organized, and Chen’s model filled that gap.
It became the foundation for Entity-Relationship (ER) modeling, a method for describing data in terms of entities, attributes, and relationships. Unlike earlier models tied to specific systems, Chen notation introduced a conceptual, platform-independent approach that was easier to understand and communicate.
The notation emphasized the importance of separating logical design from physical implementation—a principle still followed in modern database design. Though not as widely used in industry today, Chen notation remains important in education and early planning stages due to its clarity and strong focus on fundamentals.
Its influence helped shape data modeling as a structured discipline and continues to inform how we design and think about databases.
Conclusion: Understanding Chen Notation
Chen notation remains one of the most effective ways to describe the structure of a database at a conceptual level. By separating entities, attributes, and relationships using distinct symbols, it helps you build a clear and logical view of how your data is organized.
While other notations may be more common in software development today, Chen notation is still widely used in education and early-stage planning because of its clarity and completeness. Understanding it gives you a strong foundation in data modeling—and helps you think critically about how data connects and flows through a system.
Whether you’re diagramming a simple system or planning a larger database, Chen notation offers a valuable starting point for building well-structured, meaningful designs. Creately makes it easy to create Chen notation ER diagrams with built-in templates, smart shapes, and collaborative features—so you can focus on your design without getting slowed down by formatting.
References
ResearchGate. (n.d.). (PDF) A Comparative Analysis of Entity-Relationship Diagrams. [online] Available at: https://www.researchgate.net/publication/243781001_A.
Purchase, H.C., Welland, R., McGill, M. and Colpoys, L. (2004). Comprehension of diagram syntax: an empirical study of entity relationship notations. International Journal of Human-Computer Studies, 61(2), pp.187–203. doi:https://doi.org/10.1016/j.ijhcs.2004.01.003.
These extra symbols make Chen notation more expressive than some other notations. Yes. Chen notation allows you to model generalization (grouping common features of entities) and specialization (defining more specific subtypes of an entity). These are often shown using a triangle shape that connects the supertype to its subtypes, with a label like “is-a.” For example, you might show “Vehicle” as a general entity, with “Car” and “Motorcycle” as specializations. Chen notation was originally designed for relational databases, where structured tables and defined relationships are key. While it’s not a perfect fit for NoSQL systems—which are more flexible and often schema-less—you can still use it for conceptual modeling if your NoSQL data has a predictable structure. For document databases (like MongoDB), an ER diagram in Chen notation can help identify key entities and how documents relate, even if the physical implementation is different.FAQs on Chen Notation in ER Diagrams
Is Chen notation still used today?
How do derived and multivalued attributes work in Chen notation?
Can Chen notation handle hierarchical or recursive relationships?
Does Chen notation support generalization and specialization?
Is Chen notation suitable for NoSQL databases?
