Сопоставление информации о путанице?

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 для этих таблиц.

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

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