ERD Guide

Use an ERD when project requirements and decisions need to become a structured data model. Read the Markdown source of truth first, then model only the data needed by the confirmed scope.

Before creating an ERD

Clarify:

• Which user flows the model must support
• Which information must be stored
• State and permission rules
• Connections to existing systems or APIs
• Questions that remain undecided

Read the Project Context document and create an ERD draft for the required data structure.

Begin with the core flow instead of trying to complete every table at once.

Change the structure with an Agent

An Agent can create, update, and delete tables, columns, indexes, relationships, enums, and table groups as one coherent change.

Based on the requirements for users, permissions, and invitations, propose the required tables, columns, relationships, and indexes together. Show me the change list before applying it.

Confirm the targets before destructive changes, column type changes, or relationship changes because they can affect data and implementation.

Use the canvas

Arrange tables and connect relationships on the canvas. Use zoom, pan, filters, and groups to focus on relevant parts of a complex model.

Use sticky notes for design rationale, questions, and review notes. Reflect confirmed decisions in the Markdown source of truth instead of leaving them only on the canvas.

Tables and columns

Check that names match project terminology, primary keys are clear, required and optional values are distinct, types and defaults match actual use, and sensitive data is handled appropriately.

Relationships and foreign keys

Confirm cardinality, foreign-key direction, behavior on deletion or change, and whether each relationship is required or optional.

Review the current ERD relationships and foreign keys and identify missing or conflicting items.

Enums, indexes, and table groups

Use enums for constrained status or type values. If values change often or need their own attributes, consider a table.

Design indexes around actual queries and sorting. Avoid adding them to every column without considering duplication and write cost.

Use table groups to divide a large ERD by domain, using the project's own terminology.

Editing aids

Filters, copy and paste, undo and redo, and keyboard shortcuts help with editing. After a series of changes, inspect the final tables, columns, and relationships instead of relying only on the editing history.

Built-in AI and external Agents

The built-in AI on the ERD screen focuses on that ERD. A connected external Agent can also read the project's Markdown, materials, and other deliverables when working on the model.

Neither route makes the result an official standard automatically. Record reviewed decisions in the Project Context document.

Structure and layout

An Agent can list or inspect tables, relationships, enums, and groups and can arrange tables. Layout aids understanding but does not define the meaning of the data model.

Compare the ERD with requirements, screens, permission policy, and OpenAPI. When the data structure changes, inspect affected APIs and the project source of truth.

To bring in an existing schema or deliver the model outside AiNecto, continue to ERD Import, Export, and Change Management.