Relationships & Navigation Properties in EF Core

In relational databases, it is a healthy practice to divide the data between related tables. For Example, the employee working in a particular department. We do not store both the information in the same table but divide them into Employee & Department table.

When we divide tables, we also need to specify the relationships between them. For example, if you are looking for an employee working in a particular department, then you need to specify the relationship between employees and the department table. The relationship between these tables is defined using the foreign keys. We then use these relationships to query the database to get the meaningful data.

Definition of Terms

There are few terms you should be familiar with when discussing the relationships between entities

Consider the following model of Employee and Department

The entities participating in the relation can be either Principal entity or Dependent Entity

Principal Entity

The Department Model is the Principal entity (or parent) as Employee entity needs it. The Principal Entity can exist on its own. It will contain the primary/alternate key properties, which will be inserted into the Depdendent Entity

Dependent Entity

The Dependent Entity (or child) dependent on Principal Entity. The Employee Entity is the Dependent Entity here as it needs Department Entity. The Dependent Entity contains the foreign key property.

Foreign key

The Foreign Key is the glue between Principal Entity and its Dependent Entity. It is stored in the Dependent Entity and points to the Parent Entity. In the above example, DepartmentID is the Foreign Key in the Dependent Entity, which links Employee to Department.

Principal Key

The Principal Key is the property that uniquely identifies the Principal Entity and participates in the relationship. The Principal Key can be either primary key or an alternate key. The DepartmentID in the Department Entity is the Principal Key

Navigation Properties

A Navigation Property is a property that defined on the principal and/or dependent entity that contains a reference to the related entity

Navigation properties describe the relationship between two entity types. They allow us to navigate from one end of the relationship to the other end. A relationship in the Entity Framework always has two endpoints. Each endpoint, which participates in the relationship must return a navigation property describing the relationship. 

For Example Consider the Employee & Department model.

In the above example, the Department Property in the Employee class (
dependent entity) holds the reference to the Department Class (Principal entity) is one end of the relationship. The Employees Collection in Department class is part of the other end of the relationship.

There are two types of navigation properties that can be returned by the entity types depending on the type of relationship they participate.

  1. Reference Object (If the relationship is one or Zero-or-One)
    In the above example, the Department property in Employee class 
  2. Collection (If the relationship is Many)
    The Employees Collection in the Department Class

Relationship types

The relationships can come in various types. For Example, Employee can belong to one department, but the department can have many employees. An Employee can be part of many projects and projects can have many employees working under it.

There are three specific types of relationships can exists between tables

  1. One to One
  2. One to Many
  3. Many to Many

One to One relationship

The Relationship between husband and wife is an example of one to one relationship. You can have only one spouse. One to one relationship usually does not happen in database design. Because you can combine them into one table easily without breaking any rule.

For our example,  consider the domain class Employee and EmployeeAddress.  Let us assume that employee can have only one address.  This will create a one to one relationship between employee and EmployeeAddress table. In a One to one relationship PrimaryKey of one table (employeeID of employee table) is both Primary key and Foreign key in the second table (EmployeeAddress). Hence our entity classes will be as shown below

Note that we have created the navigational property which returns the reference to the related entity. In Employee class navigational property returns the reference to the EmployeeAddress object. In EmployeeAddress class navigational property returns the reference to the Employee object.

Configure one to one relationship in Entity Framework Core

One to Many Relationship

The Relationship between mother and children is an example of one to Many relationships. A Mother can have many children, but a child can have only one mother.

The relationship between employee and the department is one to many. The employee belongs to only one department. The department can have many employees. In a One to Many relationship Primary key of the department table (DepartmentID) is defined as Foreignkey in the employee’s table

Note that navigational property in the employee class returns the reference to the department object. The navigational property in Department class returns the employee’s collection. Code first uses this information to determine which class is dependent on which.

Configure One to Many Relationship in Entity Framework

Many to Many Relationship

The Relationship between siblings is Many to Many relationships. Each of your siblings can have many siblings

The relationship between employee and projects is many to many. The employee can be part of more than one project. The Projects can have many employees. The Many to Many relationships usually involves the creation of a join table. The join table will have a composite primary key consisting combination of the primary key of the both employees and project table.

Configure Many to Many relationships in Entity Framework 

Configuring the Relationship in Entity Framework

The Relationships in entity framework can be done using the following methods

  1. EF Core Conventions
  2. Data Annotations attributes
  3. Fluent API in EF Core

Default Conventions

We learned about EF Core Conventions from the Tutorial. The conventions use the default rules to build a model based on your domain classes. EF Core infers the relationships using the navigational properties and use the Conventions and builds the model.

Data Annotations Attributes

Data Annotations allow us to fine tune the model by Attributes. Key Attribute & ForeginKey Attributes are used to further configure the relationship between models

Fluent API

Fluent API Provides more power to configure the relationships in entity models. The Modelbuilder returns the PropertyBuilder to configure the entities. The PropertyBuilder exposes HasOne,HasMany, WithOne, WithMany methods which used to configure relationships. The method to be used depends on the type of relationship (one or many). These methods take navigational properties as their parameter

HasOne

Starts the Configuration of a relationship where the selected entity type has a reference navigation property that points to a single instance of the other type in the relationship.

HasMany

Starts the configuration of a relationship where the selected entity type has a collection navigation property that points to a single instance of the other type in the relationship. 

WithOne

This chained after the HasOne/HasMany and completes the Configuration of the relationship as either one-to-one or one-to-many  

WithMany

This chained after the HasOne and completes the Configuration of the relationship as either one-to-one or one-to-many.

HasMany/WithMany is not yet supported in EF Core

Reference

In the next tutorials, we will explore each of three relationships in detail.

4 thoughts on “Relationships & Navigation Properties in EF Core”

  1. Can you leave some coding examples where you navigate through the properties? I used Fluent API to build the relationships, I tried annotations and the default conventions but all my properties still return null.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top