Brand
Get all logo versions.
Download 
An entity relationship diagram (ERD) maps the data in a system: the entities, their attributes, and the relationships between them, with cardinality marking how many of each side can connect. This template is a complete worked example, a six-table e-commerce schema in crow's foot notation, with primary and foreign keys, column types, labelled relationships, and a legend decoding the line endings. Database designers copy it and swap in their own tables.
An ER diagram and a relational schema describe the same data at different stages. The ER diagram comes first: entities, relationships, and cardinality, free of any database engine, readable by non-engineers. The relational schema comes second: concrete tables, columns, types, and foreign keys for a specific database. A many-to-many relationship is one line on an ERD; in the schema it becomes a junction table. Design on the diagram, then translate.
An entity relationship diagram (ERD) is a visual model of the data in a system: the entities (objects like customer, order, or product), their attributes (the fields each entity holds), and the relationships between them, with cardinality showing whether the link is one-to-one, one-to-many, or many-to-many. Peter Chen formalized the model in 1976, and ERDs remain the standard first step in database design.
In the widely used crow's foot notation, rectangles are entities, rows inside them are attributes, and lines between them are relationships. The line endpoints carry the cardinality: a crow's foot for many, a dash for one, a circle for zero or optional. Classic Chen notation uses diamonds for relationships and ovals for attributes instead. This template draws crow's foot directly and includes a legend decoding the four line endings.
An ER diagram is the design: a conceptual picture of entities and how they relate, drawn before (or independent of) any database engine. A relational schema is the implementation: the actual tables, columns, data types, and foreign keys that realize the design in a specific database. The table-based entities in this template sit between the two, close enough to a schema to hand to an engineer.
The classic real-world example is e-commerce, which is what this template shows: a customer has addresses, places orders that ship to an address, each order contains order_items, and each order_item references a product that belongs to a category. The order_item table is the textbook move: it resolves the many-to-many between orders and products into two one-to-many relationships. School (student enrolls in course) is the other classic.
Cardinality is the number rule on a relationship: how many of one entity can link to how many of another. The three forms are one-to-one (a user has one profile), one-to-many (a customer places many orders), and many-to-many (students enroll in many courses, courses hold many students). On this template it's drawn with crow's foot endings, decoded by the built-in legend; checking each relationship's cardinality is the fastest sanity test a model gets.