Model one-to-many relationship in database

Question

I am trying to find a proper pattern to model one-to-many relationship from several tables to a common table.

EntityA, EntityB and other entities have one or many GenericInfo.

EntityA (0..1) ------ (1..N) GenericInfo

EntityB (0..1) ------ (1..N) GenericInfo

EntityC (0..1) ------ (1..N) GenericInfo

Option1: These entities are different so I cannot use a super table to model the relationships like

SuperEntity (S_Id pk)

EntityA (S_Id pk fk)

EntityB (S_Id pk fk)

GenericInfo (G_Id pk, S_id fk)

Option2: And I don't want to lose referential integrity by removing the foreign key constrain from the GenericInfo table.

EntityA (S_Id pk fk)

EntityB (S_Id pk fk)

GenericInfo (G_Id pk, unique_id non-fk)

Option3: I am currently using association tables for relationship mapping.

EntityA (A_Id pk)

EntityB (B_Id pk)

EntityAInfo(A_Id pk fk, G_Id pk fk)

EntityBInfo(B_Id pk fk, G_Id pk fk)

GenericInfo (G_Id pk)

I don't like this solution because too many tables have to be created in the database whose whole purpose is to preserve the links/relationships.

Option4: Another way I can think of is to create a mapping table with a single Id attribute like this,

EntityA (A_Id pk, I_id fk nullable)

EntityB (B_Id pk, I_id fk nullable)

InfoMapping(I_Id pk)

GenericInfo (G_Id pk, I_Id fk)

I'd love your expert opinion and input.

Thanks,

update

Vasek, thanks for your comment.

The problem I try to resolve is: How to establish object-relational mapping for an interface implementation which exposes a collection of objects?

We are using one table per class strategy for OR mapping. So each table in the example is mapped from a class. Suppose we have the following type definitions and tables (It is a pity I cannot post disgrams here)

public interface IGenericInfoProvider
{
GenericInfo [ ] GenericInfoArray {get;set;}
}

public class BaseClassForA {} --------------------------------------------- Table BaseEntityForA
public class BaseClassForB {} --------------------------------------------- Table BaseEntityForB
public class ClassA : BaseClassForA, IGenericInfoProvider {} --- Table EntityA
public class ClassB : BaseClassForB, IGenericInfoProvider {} --- Table EntityB
public class GenericInfo {} ---------------------------------------------------- Table GenericInfo

I am trying to model the one-to-many relationship between EntityA/EntityB and GenericInfo. This kind of relationships are pretty common in our domain model.
Option1 is not considered beacuse this leads to create a supertable to include all the ids from lots of tables and it doesn't make any sense in OO world.
Option2 is unacceptable because of referential integrity.
Option3 is the pattern I currently use.
I am considering Option4 but not sure if it is an approach in the right direction.

Answer 1

I am not sure what you wish to achieve, but I suppose it might be useful to try to use some database design tool to create the structure with tables, primary/foreign/alternate keys, compound keys, relationships etc. A picture is worth a thousand words :) and you can create various designs quickly, generate SQL code and think about how to store sample data.

For me the first scenario (Option 3) seems to represent M:N relationships. The second scenario (Option 4) represents different scenario - different referential integrity and therefore the two scenarios are not comparable.

Try to create sample databases, insert sample records and write queries.

Answer 2

Your current solution is the correct solution. It is the vbbest way to preserve data integrity which is the single most critical function of a database. Making more tables is something that should not even be a design consideration.