How to Draw ER Diagrams in Dia (Database Design)

Dia Tutorials · ER Diagrams · Updated October 2026

About this guide: This is an independent community resource for Dia users. We are not affiliated with the GNOME project or the Dia developers. Dia is free, open-source software released under the GNU GPL.

Entity-Relationship (ER) diagrams are the standard way to design and document relational database schemas — and Dia’s built-in ER sheet handles the classic notation well. This tutorial shows you how to model entities, attributes, and relationships in Dia, how to express cardinality, and what the honest limitations are (so you do not waste an afternoon looking for features that are not there).

First, install Dia if you have not already: our download page and the Windows installation guide have you covered.

Step 1: Open the ER Sheet

1. Launch Dia and create a new diagram.
2. In the Toolbox sheet drop-down, select ER.
3. The Toolbox now shows Entity, Relationship, and Attribute objects (plus a few helpers).

Step 2: Create Entities

1. Select the Entity tool and click the canvas — a rectangle appears.
2. Double-click it and type the entity name in singular form, e.g. Customer (not Customers — singular is the convention).
3. Place one entity per table in your planned schema. Start with the 3–5 core entities before adding details.

Step 3: Add Attributes (Columns)

1. Select the Attribute tool (the oval) and click the canvas.
2. Double-click it and type the attribute name, e.g. email.
3. Connect the attribute oval to its entity with a plain line, clicking the green connection points on both ends so the link stays glued.
4. Mark the primary key: Dia’s ER attribute properties let you flag key attributes — conventionally shown underlined in the diagram.
5. Repeat for each column. Keep attribute names consistent with the naming style your database will actually use.

Step 4: Add Relationships

1. Select the Relationship tool (the diamond) and place it between two entities.
2. Double-click it and name the relationship with a verb phrase, e.g. places (Customer places Order).
3. Connect the diamond to both entities with lines, using green connection points.
4. Set cardinality: double-click each connecting line and enter the cardinality text (e.g. 1 on the Customer side, N or 0..* on the Order side).

Cardinality cheat sheet

Step 5: Handle Many-to-Many Relationships

Relational databases cannot implement M:N directly — you need a junction table. In your Dia diagram:

1. Replace the M:N diamond with a new weak entity (e.g. Enrollment between Student and Course).
2. Draw two 1:N relationships: Student 1—N Enrollment, Course 1—N Enrollment.
3. This mirrors exactly what you will CREATE TABLE later — the diagram becomes your implementation plan.

Step 6: Review and Export

• Read it aloud: “One Customer places zero or more Orders; each Order is placed by exactly one Customer.” If the sentence sounds wrong, the diagram is wrong.
• Check every entity has a key and every relationship has cardinality on both ends.
• Save the .dia file, then File > Export to SVG or PDF for your design document. See our export quality guide.

Worked Example: Blog Database Schema

Let’s design a real schema — a simple blog. Draw along in Dia:

1. Entities: place three Entity rectangles: User, Post, Comment.
2. Attributes: User gets user_id (key, underlined), username, email, created_at. Post gets post_id (key), title, body, published_at. Comment gets comment_id (key), body, created_at.
3. Relationships: diamond writes between User (1) and Post (0..*). Diamond comments_on between User (1) and Comment (0..*). Diamond belongs_to between Comment (0..*) and Post (1).
4. Tags (M:N): add entity Tag with tag_id (key), name. A Post can have many Tags and a Tag many Posts — that’s M:N, so insert weak entity PostTag with two 1:N relationships instead of one M:N diamond.
5. Read it aloud: “One User writes zero or more Posts; each Post is written by exactly one User.” If every sentence checks out, your schema is sound.

This diagram now maps 1:1 to your CREATE TABLE statements — entities become tables, key attributes become PRIMARY KEYs, and 1:N relationships become FOREIGN KEY columns on the “many” side.

From ER Diagram to Tables: Translation Checklist

• Entity → table. Entity name becomes the table name (pluralize if your convention says so).
• Key attribute → PRIMARY KEY. Every entity must have one — no exceptions.
• 1:N relationship → foreign key on the “many” side pointing at the “one” side’s key.
• 1:1 relationship → foreign key on either side (plus a UNIQUE constraint).
• M:N → junction table (the weak entity you drew), with two foreign keys forming a composite primary key.
• Multivalued attribute → separate table (e.g. phone_numbers becomes its own table with a foreign key).

Normalization Sanity Checks

Before you finalize any ER diagram, run these five checks — they catch 90% of design errors:

1. Every entity has a primary key. No key, no table. If you can’t identify one, you probably need a surrogate key (e.g. auto-increment id).
2. No repeating groups. If an entity has phone1, phone2, phone3, that’s a multivalued attribute in disguise — split it into its own entity.
3. Every non-key attribute depends on the whole key. In a PostTag(post_id, tag_id, tag_name) table, tag_name depends only on tag_id — move it to Tag. (This is second normal form.)
4. No transitive dependencies. If Order has customer_id and customer_email, the email depends on the customer, not the order — drop it from Order. (Third normal form.)
5. Every relationship is justified. For each diamond, ask: “What query does this enable?” If none, it’s decoration — delete it.

Naming Things Well

Database diagrams live for years, so names matter more here than anywhere else in Dia:

• Entities: singular nouns (Customer, not Customers). An entity describes one instance of the concept.
• Attributes: snake_case if your database uses it (created_at), and keep the exact names you plan to use in DDL — the diagram doubles as a naming spec.
• Relationships: verb phrases that read naturally in both directions where possible (places / placed by).
• Avoid abbreviations nobody outside your team knows. cust_acct_stat_cd might save typing, but customer_account_status saves misunderstandings.

Documenting Constraints and Business Rules

Not every rule fits in boxes and diamonds. Use Dia’s Note objects (from the UML or Assorted sheet) to pin business rules next to the entities they constrain: “A Member may have at most 5 active Loans”, “email must be unique”, “soft-delete: never remove rows, set deleted_at”. Connect each note to its entity with a dashed line. These annotations turn a bare schema sketch into a specification a developer can actually implement from — and they cost ten seconds each.

Frequently Asked Questions