Why BAs need to understand ER diagrams
You do not need to design databases to be a Business Analyst. But you do need to understand the data your system manages. An Entity-Relationship diagram (ERD) is the clearest way to see what data exists, how it is related, and what business rules are enforced through the data structure.
When you read an ERD, you can spot missing requirements ("what happens to orders when a customer is deleted?"), identify business rules embedded in the structure ("a customer can have multiple addresses, but only one can be primary"), and validate that the data model supports the reporting requirements you have specified.
The four building blocks
1. Entities
An entity is a thing the business needs to track — a Customer, an Order, a Product, a Payment, an Employee. Entities become tables in a database. They appear as rectangles in an ERD. Every entity must have a primary key — a unique identifier that distinguishes one record from another (Customer ID, Order Number, Product SKU).
2. Attributes
Attributes are the properties of an entity. A Customer has a name, an email address, a phone number, and a date of birth. These appear as fields within the entity box. As a BA, your job is to identify which attributes are mandatory (cannot be empty), which are unique (no two records can have the same value), and which are the primary key.
3. Relationships
Relationships show how entities connect to each other. A Customer places Orders. An Order contains Products. A Payment covers an Order. Relationships are expressed as verbs connecting two entity rectangles.
4. Cardinality
Cardinality tells you how many instances of one entity can relate to how many instances of another. The three types:
- One-to-one (1:1): One employee has one employee record. Rare in practice.
- One-to-many (1:N): One customer places many orders. One order contains many line items. The most common relationship.
- Many-to-many (M:N): Many students enrol in many courses. Many products appear in many orders. Always resolved with a junction table (Order_Item, Student_Enrolment).
CUSTOMER ||--o{ ORDER means: one customer (||) places zero or more orders (o{). The double line means "exactly one". The circle means "zero". The crow's foot means "many".
How to use ERDs in your BA work
Validating requirements against the data model
Ask the developer or architect to walk you through the ERD for your system. Check: does the data model support every report you have specified? Can every search filter be executed? Does the structure support the audit trail requirements?
Identifying missing requirements
Look at every relationship and ask what happens when one side is deleted. If a Customer is deleted, what happens to their Orders? Their Payment records? Their Support Tickets? These are business rules that must be in your requirements.
Spotting misunderstood requirements
If the data model has a Customer table with a single address field, but your requirements say customers can have multiple delivery addresses, there is a mismatch. Catch it on the ERD before it gets into development.
⚡ ER diagram in SmartPrompt
SmartPrompt generates ER diagrams from your requirements. Select the Entity Relationship Description template to get a structured specification and a rendered ERD.
Open ER Diagram Template →The BA's ER diagram checklist
- Every entity has a primary key
- Every mandatory relationship is documented
- All many-to-many relationships have junction tables
- The deletion behaviour for all relationships is defined
- The data model supports all specified reports and filters
- Audit columns (created_at, updated_at, deleted_at) exist for all key entities