HACK: Exposing Foreign Keys as Properties through the ADO.NET Entity Framework

First post for months; the PerformancePoint Planning announcement forced some redirection and rebuilding.  We’ve grieved, we’ve moaned, but at some point, you just have to move on.


I’m not a fan of hacks – it normally means you are doing something wrong, but in this case, where I’m after a quick win, I’ve had to work out and resort to a bit of a hack.  It actually looks like the issue I’m facing maybe addressed in Entity Framework v2 (Microsoft .NET 4.0) – so maybe it’s more of a workaround than a hack after all ;o)

I’m using the ADO.NET Entity Framework and ADO.NET Data Services to expose a subsection of a database for consumption by Gemini.  In order to relate the exposed database objects together in Gemini, I need to apply this hack to ensure I have Foreign Keys available in my Gemini models to support creating the relationships.  By default, the Entity Framework exposes Foreign Keys as Navigation Properties rather than Scalar Properties.  Gemini does not consume Navigation Properties.

Lets take the scenario where I want to create an Entity Framework Model based on the following tables from the AdventureWorksDW2008 sample database:


Step 1)  Identify the table(s) that contain Foreign Keys.

In this case FactInternetSales.

Step 2)  Load those table(s) into the Entity Framework Model on their own.

This ensures the Foreign Keys are set as Scalar Properties.  If you load in all the tables at once, the Foreign Keys are not exposed as Scalar Properties.

Step 3)  Load in the related tables. (DimCustomer, DimProduct, DimSalesTerritory)

At this point a bunch of Navigation Properties would have been set up, along with relationships between the related tables but the trouble now is the project will no longer build.  If you try you receive the following error for each relationship:

Error 3007: Problem in Mapping Fragments starting at lines 322, 428: Non-Primary-Key column(s) [CustomerKey] are being mapped in both fragments to different conceptual side properties – data inconsistency is possible because the corresponding conceptual side properties can be independently modified.

Step 4) Manually remove the relationships between tables.

Clicking on the relationship line on the diagram and hitting delete, removes the relationship.

Step 5) Remove all Association Sets

By editing the edmx file manually in a text or XML editor you need to remove all … occurrences from the section:

<EntityContainer Name="AdventureWorksDW2008Model1StoreContainer"> 
    <EntitySet Name="DimCustomer" EntityType="AdventureWorksDW2008Model1.Store.DimCustomer" … /> 
    <EntitySet Name="DimProduct" EntityType="AdventureWorksDW2008Model1.Store.DimProduct" … /> 
    <EntitySet Name="DimSalesTerritory" EntityType="AdventureWorksDW2008Model1.Store.DimSalesTerritory" … /> 
    <EntitySet Name="FactInternetSales" EntityType="AdventureWorksDW2008Model1.Store.FactInternetSales" … /> 
    <AssociationSet Name="FK_FactInternetSales_DimCustomer" Association="AWDW08.FK_FactInternetSales_DimCustomer"> 
        <End Role="DimCustomer" EntitySet="DimCustomer" /> 
        <End Role="FactInternetSales" EntitySet="FactInternetSales" /> 
    <AssociationSet Name="FK_FactInternetSales_DimProduct" Association="AWDW08.FK_FactInternetSales_DimProduct"> 
        <End Role="DimProduct" EntitySet="DimProduct" /> 
        <End Role="FactInternetSales" EntitySet="FactInternetSales" /> 
    <AssociationSet Name="FK_FactInternetSales_DimSalesTerritory" Association="ADW08.FK_FactInternetSales_DimSalesTerritory"> 
        <End Role="DimSalesTerritory" EntitySet="DimSalesTerritory" /> 
        <End Role="FactInternetSales" EntitySet="FactInternetSales" /> 

The project should now build, with the foreign keys exposed as Scalar Properties.  Obviously no inherent relationships exist, so this could be dangerous in certain applications.  For Gemini however, providing you setup the relationships manually, it works a treat.