dazedorconfused wrote:
ok, so... sorry if I am essentially asking the same question again
I have 2 tables...
Employee
UID uniqueidentifier(PK)
LastName varchar(100)
FirstName varchar(100)
DepartmentID uniqueidentifier (FK)
Department
UID uniqueidentifier(PK)
Name varchar(100)
There is a relationship from Employee to Department on Emplyee.DepartmentUID = Department.UID
When I add the entities, a field named Employee gets added to the Department Entity based on the relationship. Likewise on the Employee object, a field named Department has been add based on the relationship. I would expect the second action, as an Employee "has a" Department. But a Department doesn't have an Employee. (It has, or can have Employees). So, do I remove the related field Employee from the Department Entity and then add a Typed List (of Employee Entities)?
I hope this makes sense.
An FK is a referential integrity relation which is interpreted as 2 relations: PK -> FK and FK -> PK.
You shouldn't look at it like 'This department can have 0 employees, so it shouldn't have an employees collection', as that would cause problems in your code because what happens when a department does have employees?
You should look at it as: Department can have 0 or more employees, and therefore has a relation Department 1:n Employee, and a field mapped onto that relation, namely Employees (you can rename these fields in the designer).
This then is generated into code and a Department instance (object) has an Employees collection but it can be empty, which means it doesn't have any employees, but it cal also be filled in the case where it does have employees.
The relation IS there, due to the Employee -> Department relation.
In the current version you can hide relations though that's not recommended for 1:n relations. We'll remove that feature in v2.