Entity Framework One-To-One Mapping Issues

Question

Using VS 2010 beta 2, ASP.NET MVC.

I tried to create an Entity framework file and got the data from my database.

There were some issues with the relationships, so I started to tweak things around, but I kept getting the following error for simple one-to-one relationships

Error 1 Error 113: Multiplicity is not valid in Role 'UserProfile' in relationship 'FK_UserProfiles_Users'. Because the Dependent Role properties are not the key properties, the upper bound of the multiplicity of the Dependent Role must be *. myEntities.edmx 2024

My Users table is consists of some other many-to-many relationships to other tables, but when I try to make a one-to-one relationship with other tables, that error pops up.

Users Table

• UserID
• Username
• Email

etc..

UserProfiles Table

• UserProfileID
• UserID (FK for Users Table)
• Location
• Birthday

Jolly

Answer 1

For one-to-one relationships, EF expects that the tables are using the same primary key. And really, if it's a true one-to-one they probably should. So in your example, if you make UserID the primary key on the UserProfiles table, your one-to-one will work.

Aguilera

I got this issue trying to setup a 0..1 to 1 relationship between a main table and an extension table. The extensiontable as a lot of other relations so I do not want to mess with the PK of that one. Any ideas how to resolve this type of situation? – Misdemeanor

@junior: that's a foreign key relationship and you can get there by selecting the relationship, going into the properties, and changing "End1 Multiplicity" and "End2 Multiplicity" settings (not sure if this is VS 2010-only, though). Most likely, you'll be setting "End2 Multiplicity" to "0..1". – Aguilera

There is no "should", even if EF can't correctly handle normal RA multiplicities and thus forces a perfectly good RA design to be changed. This doesn't imply that the model should be changed, current case aside - means that EF, and it still seems broken today, should be fixed to correctly model the RA database domain. – Resolve

I was very careful in my reply and I stand by the "probably should" (I agree with the shunning of absolutes and proscriptions, which is why I'm careful in such things). That said, I agree that it'd be a benefit if EF accommodated the use case without requiring that it use the same key. – Aguilera

Emphasis matters, a lot. The "should" is a filter-down of EF limitations (which are quite severe in that it only honors cardinality off of a PK), not of RA or it's SQL implementation. While I agree that this case could lead to a simple schema alteration, such is not always feasible - or correct given the FDs. Bending to EFs approach shuns out a good bit of RA, even when valid FKs are provided. – Resolve

Answer 2

I have a similar issue, but with a sale and layby scenario.

A layby can exist without a sale, and a sale can exist without a layby. This means I have a 0 or 1 to 0 or 1 relationship.

Layby references sale, but layby cannot use the primary key of Sale, and Sale cannot use the primary key of Layby.

I solved the problem by using a 0 or 1 to many relationship, configured the 'Laybys' getter and setter on the sale as private, and then provided my own 'Layby' getter and setter in my POCO.

Hartshorn

I'm curious, did you ever find a better way to capture this kind of relationship? – Suture

Answer 3

Make composite primary key set for two columns UserProfileID and UserID

Obliteration