Путаница в деталях сопоставления ассоциаций?

Question

Я никогда не понимал, почему ассоциации в EntityFramework выглядят так же, как в окне Сведения о сопоставлении.

Когда я выбираю линию между 2 таблицами для ассоциации, например FK_ApplicationSectionsNodes_FormItems, она показывает это:

Association
  Maps to ApplicationSectionNodes
    FormItems
      (key symbol) FormItemId:Int32     <-->     FormItemId:int
    ApplicationSectionNodes
      (key symbol) NodeId:Int32         <-->     (key symbol) NodeId : int

К счастью, этот файл был создан автоматически для меня на основе ограничений внешнего ключа в моей базе данных, но всякий раз, когда нет никаких ограничений, мне сложно создавать ассоциации вручную (когда база данных не имеет настройки диаграммы), потому что я не надеваю не понимаю детали отображения для ассоциаций.

Таблица FormItems имеет столбец идентификации первичного ключа FormItemId, а ApplicationSectionNodes содержит столбец FormItemId, который является внешним ключом и имеет NodeId в качестве столбца идентификации первичного ключа.

Что на самом деле не имеет смысла для меня, так это то, почему у ассоциации есть что-то, перечисленное о NodeId, когда NodeId не имеет никакого отношения к связи с внешним ключом? (Это еще более запутанно с самообращением отношения, но, может быть, если бы я мог понять вышеупомянутый случай, я бы лучше справился).

CREATE TABLE [dbo].[ApplicationSectionNodes](
    [NodeID] [int] IDENTITY(1,1) NOT NULL,
    [OutlineText] [varchar](5000) NULL,
    [ParentNodeID] [int] NULL,
    [FormItemId] [int] NULL,
 CONSTRAINT [PK_ApplicationSectionNodes] PRIMARY KEY CLUSTERED 
(
    [NodeID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY],
 CONSTRAINT [UQ_ApplicationSectionNodesFormItemId] UNIQUE NONCLUSTERED 
(
    [FormItemId] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[ApplicationSectionNodes]  WITH NOCHECK ADD  CONSTRAINT [FK_ApplicationSectionNodes_ApplicationSectionNodes] FOREIGN KEY([ParentNodeID])
REFERENCES [dbo].[ApplicationSectionNodes] ([NodeID])
GO
ALTER TABLE [dbo].[ApplicationSectionNodes] NOCHECK CONSTRAINT [FK_ApplicationSectionNodes_ApplicationSectionNodes]
GO
ALTER TABLE [dbo].[ApplicationSectionNodes]  WITH NOCHECK ADD  CONSTRAINT [FK_ApplicationSectionNodes_FormItems] FOREIGN KEY([FormItemId])
REFERENCES [dbo].[FormItems] ([FormItemId])
GO
ALTER TABLE [dbo].[ApplicationSectionNodes] NOCHECK CONSTRAINT [FK_ApplicationSectionNodes_FormItems]
GO

Таблица FormItems:

CREATE TABLE [dbo].[FormItems](
    [FormItemId] [int] IDENTITY(1,1) NOT NULL,
    [FormItemType] [int] NULL,
 CONSTRAINT [PK_FormItems] PRIMARY KEY CLUSTERED 
(
    [FormItemId] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

GO
ALTER TABLE [dbo].[FormItems]  WITH NOCHECK ADD  CONSTRAINT [FK_FormItems_FormItemTypes] FOREIGN KEY([FormItemType])
REFERENCES [dbo].[FormItemTypes] ([FormItemTypeId])
GO
ALTER TABLE [dbo].[FormItems] NOCHECK CONSTRAINT [FK_FormItems_FormItemTypes]
GO

Answer 1

Это выглядит неправильно, вы можете добавить фактическое определение внешнего ключа, которое находится в базе данных, либо в виде изображения из диалога редактора внешних ключей SSMS, либо из сценария базы данных из SSMS для этих таблиц.

EF не запустил бы случайно NodeId, если бы он не был указан в вашем внешнем ключе.

Проверьте вашу базу данных.