ER Diagram Symbols

Master the visual language of ER diagrams by learning every symbol, notation, and drawing convention that database designers use to communicate complex data structures.

ER diagrams use a specific visual language. Think of it like reading a blueprint - architects have standard symbols for doors, windows, and electrical outlets. Database designers have standard symbols for entities, attributes, and relationships.

Every symbol means something precise. A rectangle isn't just a shape - it represents an entity. A diamond isn't decoration - it shows a relationship. Understanding these symbols lets you read any ER diagram and communicate your database designs clearly.

Entity Symbols

Entities represent the "things" in your database. They get drawn as rectangles with the entity name inside. Simple, but there are important variations.

Strong entities exist independently. A Customer can exist whether they've placed orders or not. Weak entities need a parent to exist. An OrderItem only makes sense if an Order exists first.

BookVault has both types. Books, Authors, and Customers are strong entities - they exist on their own. OrderItems are weak entities - they can't exist without an Order.

Attribute Symbols

Attributes describe entity properties. They get drawn as ovals connected to entities. But different attribute types use different symbols.

Why does this matter? Different attribute types become different database columns. A composite attribute like "address" might become multiple columns: street, city, state, zip_code.

Relationship Symbols

Relationships connect entities. They get drawn as diamonds with the relationship name inside. The connecting lines show how many instances participate.

The diamond contains the relationship verb - "places", "contains", "writes". The lines show cardinality - how many of each entity can participate.

Cardinality Notation

Different notation styles exist for showing cardinality. Chen notation uses 1, M, N labels. Crow's foot notation uses symbols that look like bird feet.

BookVault uses Chen notation because it's clearer for learning. A Customer places many Orders (1:M). An Order contains many Books, and a Book appears in many Orders (M:N).

Advanced Symbols

Real databases need more sophisticated symbols for complex scenarios. These handle inheritance, participation constraints, and multi-valued attributes.

Participation Constraints

Does every entity instance have to participate in a relationship? Total participation means yes - drawn with double lines. Partial participation means optional - drawn with single lines.

Multi-valued Attributes

Some attributes can have multiple values. A Book might have multiple genres. These get drawn as double ovals - an oval inside another oval.

Multi-valued attributes create implementation challenges. You can't store multiple genres in a single database column easily. Usually, you create a separate table instead.

ISA Relationships (Inheritance)

Sometimes entities share common attributes but have specialized properties. Think "User" as a parent, with "Customer" and "Admin" as children. This uses ISA triangles.

Symbol Combinations in Practice

Real ER diagrams combine all these symbols. Here's how BookVault's Order and OrderItem relationship looks with proper notation:

Notice the symbols working together. The OrderItem entity has a double border (weak entity). The relationship line has double thickness (total participation). The order_id attribute shows as FK (foreign key).

From Symbols to SQL

These symbols translate directly to SQL table structure. Here's how the above diagram becomes actual database tables:

-- Strong entity becomes independent table
-- Primary key from key attribute (underlined in ER diagram)
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT NOT NULL,
    order_date DATE NOT NULL,
    total_amount DECIMAL(10,2)
);

-- Weak entity becomes dependent table  
-- Foreign key relationship enforces total participation
CREATE TABLE order_items (
    order_item_id INT PRIMARY KEY,
    order_id INT NOT NULL,           -- FK from parent entity
    book_id INT NOT NULL,
    quantity INT NOT NULL,
    unit_price DECIMAL(10,2),
    FOREIGN KEY (order_id) REFERENCES orders(order_id)
        ON DELETE CASCADE            -- Weak entity dies with parent
);

Table 'orders' created successfully.
Table 'order_items' created successfully.

Foreign key constraint 'order_items_ibfk_1' applied:
- order_items.order_id → orders.order_id  
- CASCADE DELETE enabled (weak entity behavior)

Reading vs Drawing ER Diagrams

You'll read ER diagrams more often than draw them. But understanding symbols helps both activities. When you see a diagram, ask these questions:

Professional tip: most database design tools handle symbol drawing for you. Focus on understanding what each symbol means rather than perfect drawing technique.

Quiz