ERD database design guide - guia AI
Esta guia resume buenas practicas de ERD database design guide para equipos tecnicos.
What is an entity relationship diagram?
An ERD represents data as entities (tables), attributes (columns), and relationships (foreign key constraints). Each entity becomes a table in your database. Each attribute becomes a column. Each relationship line represents a JOIN — and the cardinality notation (1:1, 1:N, M:N) tells you how many rows of one table relate to rows of another.
ERDs come in two flavours: conceptual ERDs show the logical data model without implementation details, and physical ERDs include data types, primary keys, foreign keys, and indexes — essentially a blueprint for the DDL SQL you'll run.
Common tools for ERDs include dbdiagram.io, draw.io, Lucidchart, and ERDPlus. AIDrawIO generates ERDs from a plain-English description of your schema, producing draw.io XML that you can edit and export.
Crow's Foot vs Chen notation
Crow's Foot notation (also called 'Information Engineering' notation) is the most common in modern tools. Relationship cardinality is shown using symbols on the ends of lines: a single vertical line means 'one', a crow's foot (three lines fanning out) means 'many', and a circle means 'zero'. A 'zero-or-many' relationship uses a circle + crow's foot. 'One-or-many' uses a single line + crow's foot.
Chen notation (from Peter Chen's 1976 paper) uses rectangles for entities, ovals for attributes, diamonds for relationship types, and labels the cardinality (1, N, M) on the connecting lines. Chen notation is more commonly used in academic contexts and database theory courses.
For modern software engineering, Crow's Foot is the standard. It's more compact and is supported by default in draw.io, dbdiagram.io, and most database modeling tools. AIDrawIO generates Crow's Foot notation in its ERD output.
Designing a normalized ERD
Normalization removes redundancy from a database schema. First Normal Form (1NF) requires that every column contains atomic values (no arrays in a cell). Second Normal Form (2NF) requires that every non-key attribute depends on the whole primary key. Third Normal Form (3NF) requires that every non-key attribute depends only on the primary key, not on other non-key attributes.
In practice, most production databases target 3NF for transactional data. Common signs of poor normalization: storing a user's email address in three different tables (duplication), storing a comma-separated list in a column (violates 1NF), or storing a derived value like 'total price' rather than computing it from unit price and quantity (violates 3NF).
Many-to-many relationships require a junction table. If an Order can have many Products, and a Product can appear in many Orders, you need an order_items table with order_id and product_id foreign keys plus a quantity column. Always look for implicit M:N relationships in requirements — they're a common source of schema bugs.
Generate an ERD from a description with AI
Describe your schema in plain English — 'Ecommerce schema: users, orders, order_items, products, categories, addresses — with primary and foreign keys' — and AIDrawIO generates a complete Crow's Foot ERD with correct relationships, cardinality notation, and labeled columns.
The output is draw.io XML. Open it in diagrams.net, add your specific column names and data types, and you have a physical ERD ready for your team review. Export as PNG for documentation or SVG for your wiki.
Experimente gratis ERD generator
AI entity-relationship diagrams. Describe in plain English, get draw.io XML in seconds. No account required.
Perguntas frequentes
What is the difference between an ERD and a schema diagram?
They're closely related. An ERD can be conceptual (showing entities and relationships without implementation detail) or physical (showing tables, columns, data types, and constraints). A 'schema diagram' typically refers to a physical ERD. Most tools use the terms interchangeably.
How do you show a many-to-many relationship in an ERD?
A true M:N relationship between two entities requires a junction (associative) table. In the ERD, draw the junction table as a separate entity and create 1:N relationships from each parent entity to the junction. For example, Order → OrderItem ← Product.
What data types should I show on an ERD?
For a physical ERD, include the data type for each attribute: VARCHAR(255), INT, TIMESTAMP, BOOLEAN, etc. Also mark primary keys (PK), foreign keys (FK), and any NOT NULL constraints. For a conceptual ERD, data types are optional.
Can I generate an ERD from an existing database?
Yes — most database clients can reverse-engineer an ERD from a live schema. TablePlus, DBeaver, and pgAdmin all have this feature. Alternatively, describe your existing schema to AIDrawIO and it will generate an ERD you can use as a documentation starting point.