erd.md

ERDs

Check out this overview from LucidCharts. Here is their written guide.

Reading Diagrams

In ERDs, so much information can be shared at a glance if you know how to read the specific arrows and shapes used.

You can indicate entities, relationships, and attributes by differing their shapes, as shown below.

Arrows

Crow's feet notation shows the maximum (cardinality) and minimum (ordinality) number of times an instance of an entity can relate to instances of another entity.

While this is all useful information when planning, today we'll focus on the use of crow's feet to indicate the relationships between entities.

Making Diagrams

Our approach today will represent entities as tables, with columns as their attributes. We'll use crow's feet notation to indicate the relationships.

For every model you have, you'll want to create a table in your ERD. If the models have a 1:M relationship, store the PK (primary key) of the 1 as an FK (foreign key) on the many table. If you have a N:M, store the PKs of each model in a join table.

Think of all the information you can:

• table name
• relationship between models/entities
• attribute name
• attribute data type

Ex 1: school with students and classes

Models: student, class, school

We want to know the name and location of the school, and how many classes they offer, so imagine a schools table:

id	name	location	classCount
Number	String	String	Number

Now imagine a students table to track a name, email, and an enrollment status:

id	name	email	enrolled	schoolId
Number	String	String	Boolean	Number

And a classes table will hold information on that class instance:

id	instructor	course	title	schoolId
Number	String	Number	String	Number

One instance of a school can have many students, and one student should go to only one school, so the relationship is 1:M. The students is the many side, so that table gets the foreign key.

One instance of a class should only belong to one school, but one school could have many classes, so the relationship is 1:M. The classes is the many side so that table gets the foreign key.

One instance of a student can have many classes, and one instance of a class can have many students -- we have a N:M relationship!

To store records of which students are enrolled in which classes, we'll need a JOIN table, students_classes:

id	studentId	classId
Number	Number	Number

Ex 1. Final ERD

Ex 2. projects, categories, users

Lets make an ERD for the express-project-organizer, with category and project models, and new model: user.

projects table:

id	githubLink	name	deployLink	description	userId
Number	String	String	String	String	Number

categories table:

id	name
Number	String

users table:

id	email	password
Number	String	String

Relationships:

• there is no relationship between users and categories
• one instance of an user could have zero or many projects, but an instance of a project should belong to just one user -- 1:M, where projects gets the FK.
• one instance of a project could have zero or many categories. one category could have zero or many projects associated -- N:M, so we need a join table!

categoriesProjects table:

id	categoryId	projectId
Number	Number	Number

Ex 2. Final ERD

ERD Resources

Drawio VSCode Extension

Video: Using Drawio