Как смоделировать таблицу с внешним ключом для дочерней сущности в Fluent API EF Core?

Question

Я изменяю код C#, сгенерированный командой EF Core scaffold. Я переписал сгенерированные классы, чтобы отразить мою бизнес-модель. Моя цель - изменить вызовы Fluent API в сгенерированном коде, чтобы они лучше соответствовали моей бизнес логике c и дизайну таблицы. Мне нужна помощь, зная, какие функции вызывать и с какими параметрами.

У меня есть несколько отношений один-к-одному, в которых зависимый объект является необязательным. Я делаю это, делая целочисленное поле в главной таблице пустым; это поле является внешним ключом, который указывает на зависимую запись в другой таблице. Зависимый не знает о родителе, и это нормально, потому что мой бизнес-логика c хороша без него. У меня нет DbSet <>, объявленного в DbContect для зависимой сущности.

Во ВСЕХ документациях и учебных пособиях, которые я нашел онлайн за последние четыре дня, предполагается, что моя зависимая таблица имеет внешний ключ, который указывает на принципал, но это не тот случай. Я разработал его таким образом, чтобы было легко увидеть по основной таблице, что зависимая запись возможна, но не обязательна. Также легко сделать дочерний элемент обязательным, сделав это поле int необнуляемым.

public class Business
{
  public int Id {get; private set;}
  public string BusinessName {get; set;}
  public string BusinessLicenseNumber {get; set;}
  public Address Address {get; set;} //Address CAN be null
}

public class Address
{
  public int Id {get; private set;}
  public string Line1 {get; set;}
  public string Line2 {get; set;}
  public string City {get; set;}
  ...
}

Table Businesses
int Id Identity
varchar(50) BusinessName Non-Null
char(10) BusinessLicenseNumber Nullable
int AddressId Nullable // <<===!!

Table Addresses
int Id Identity
varchar (50) Line1 Non-Null
varchar (50) Line2 Nullable
varchar (50) City Nullable
...

Если бы вы могли предоставить URL-адрес, пример или объяснение того, что я должен делать с этим типом one-to одно отношение, это было бы замечательно, потому что оно не соответствует ничему из того, что я нашел до сих пор, но мне действительно нравится этот тип объектной и табличной модели.