Advanced EF Core 7

Course
Day 5 n 6: Relationships in EF Core 7
Relationships in EF Core 7
Abhishek Luv
Relationships in object models
• A relationship defines how two entities relate to each other. For example, when
modeling posts in a blog, each post is related to the blog it is published on, and the
blog is related to all the posts published on that blog.
• In an object-oriented language like C#, the blog and post are typically represented by
two classes: Blog and Post. For example:
Relationships in object models
• In the classes above, there is nothing to indicate that Blog and Post are related. This
can be added to the object model by adding a reference from Post to the Blog on
which it is published.
• Likewise, the opposite direction of the same relationship can be represented as a
collection of Post objects on each Blog.
• This connection from Blog to Post and, inversely, from Post back to Blog is known as
a "relationship" in EF Core.
Relationships in relational databases
• Relational databases represent relationships using foreign keys. For example, using
SQL Server or Azure SQL, the following tables can be used to represent our Post and
Blog classes:
Mapping relationships in EF Core
• EF Core relationship mapping is all about mapping the primary key/foreign key
representation used in a relational database to the references between objects used
in an object model.
Mapping relationships in EF Core
• The primary key property of Blog, Blog.Id, and the foreign key property of Post,
Post.BlogId, can then be associated with the references ("navigations") between the
entity types (Blog.Posts and Post.Blog). This is done automatically by EF when
building a simple relationship like this, but can also be specified explicitly when
overriding the OnModelCreating method of your DbContext
Different types of relationships
• EF supports many different types of relationships, with many different ways these
relationships can be represented and configured.
• One-to-many relationships, in which a single entity is associated with any number of
other entities.
• One-to-one relationships, in which a single entity is associated with another single
entity.
• Many-to-many relationships, in which any number of entities are associated with any
number of other entities.
One-to-many relationships
• In the relational database, a one-to-many relationship is a common type of
relationship between two tables where a row in a table can associate with multiple
rows in another table.
• For example, a department can have multiple employees while an employee belongs
to one department. Therefore, the Departments has a one-to-many relationship with
the Employees table.
• The one-to-many relationship is also known as the parent-child relationship. The
Departments is called a parent table while the Employees table is called a child table.
• To establish the one-to-many relationship between the Departments and Employees
tables, the Employees table needs to have a foreign key column called DepartmentId
that references the Id column of the Employees table:
One-to-many relationships
One-to-many relationships
• If the DepartmentId column accepts NULL, you can insert a row into the Employees
table without specifying a corresponding row in the Departments table. In this case,
the employee doesn’t belong to any department.
• However, if the DepartmentId column doesn’t accept NULL, you need to use an Id
from the Departments table for inserting a new row into the Employees table.
• In this case, an employee must belong to a specific department. In other words, you
need to have at least one row in the Departments table first before you can insert
rows into the Employees table.
Required One-to-many relationships
Required One-to-many relationships
In this example:
• The Department class has a property that is a collection of Employee objects.
• The Employee class has two properties DepartmentId and Department. The
DepartmentId is called a foreign key property, which is marked as required.
• This makes the one-to-many relationship required because each Employee must
associate with at least a Department.
• The Department property is known as a navigation property.
Optional One-to-many relationships
In this example:
• Since the DepartmentId and Department properties are nullable, you can create an
Employee object without a Department.
1-to-m relationships (Fluent API) Required
Optional 1-to-m relationships (Fluent API)
One-to-one relationships
• In a relational database, a one-to-one relationship allows you to link two tables so
that a row in one table is associated with at most a row in another table.
• For example, an employee can have a profile containing phone and email.
• The reason we don’t put these fields in the same Employees table is that we may
rarely use the phone and email when we work with Employee objects.
• In the database, we’ll have two separate tables Employees and EmployeeProfiles. The
EmployeeProfiles table will have a foreign key EmployeeId that references the Id of
the Emloyees table:
One-to-one relationships
One-to-one relationships
In these classes:
• The Employee class has a property Profile that is a reference navigation to the
EmployeeProfile class (child).
• The EmployeeProfile has a required foreign key property EmployeeId and reference
navigation into the Employee (parent).
• EF Core creates a unique index on the EmployeeId column of the EmployeeProfiles
table to ensure that one row in the Employees table can be associated with at most
one row in the EmloyeeProfiles table.
• EF Core also sets the ON DELETE CASCADE on the foreign key EmployeeId in the
EmployeeProfile table.
• Therefore, if you delete a row from the Employees table, the corresponding row in
the EmployeeProfile is also deleted.
• By convention, required relationships are configured to cascade delete. This is
because the dependent cannot exist in the database once the principal has been
deleted.
One-to-one relationships (Fluent API)
Many-to-many relationships
• Many-to-many relationships allow you to associate multiple rows from a table with
multiple rows in another table.
• For example, an employee can have multiple skills while a skill is processed by
multiple employees. Therefore, the relationship between employees and skills is a
many-to-many relationship.
• To model a many-to-many relationship between two tables, we often use a junction
table and two one-to-many relationships:
Many-to-many relationships
In this diagram, the EmloyeeSkill is a junction table that has two columns:
• EmployeeId – the employee’s Id that references the Id column in the Employees table.
the EmployeeId is a foreign key to the Employees table.
• SkillId – the skill’s Id that references the Id column in the Skills table. The SkillId
column is a foreign key to the Skills table.
• Also, EmployeeId and SkillId columns form the primary key of the EmployeeSkill
table.
• Since the primary key has two columns, it is called a composite key.
• It ensures that one employee possesses one skill at one time and vice versa.
Many-to-many relationships
The easiest way to model a many-to-many relationship between two entities is to
define a navigation property at both ends.
In this example, the Employee class has a collection of Skills and the Skill class has a
collection of Employees.
Many-to-many relationships(Fluent API)
This relationship is mapped by convention. Even though it is not needed, an equivalent
explicit configuration for this relationship is shown below as a learning tool.
Even with this explicit configuration, many aspects of the relationship are still
configured by convention.
M-to-M rel(Fluent API) with named join table
Everything else about the mapping remains the same, with only the name of the join
table changing:
Thanks for joining!
Abhishek Luv